1.準備
Flink CDC の原理の学習を開始する前に (この記事では最初に CDC1.0 バージョンを紹介し、後で 2.0 の機能の紹介を拡張します)、次のタスクを実行する必要があります (この記事は Flink1.12 環境から開始します) )
-
Flink の公式 Web サイトを開きます (Connector モジュールの紹介を参照してください)。
-
Github を開いてソースコードをダウンロードします (リンクは現在配置できません。読者は自分で github を検索できます)。
Apache フリンク
flink-cdc-connectors
借金
- 沈み始める
2. 設計提案
2.1. デザインの動機
CDC (変更データ キャプチャ、変更データのキャプチャ) は、企業で比較的一般的なモデルであり、主にデータ同期、検索インデックス、キャッシュ更新、およびその他のシナリオで使用されます。初期のコミュニティは、変更ログをテーブルに直接抽出して解釈する機能をサポートする必要があります。 Flink の使用シナリオを広げるAPI および SQL 関数。
一方、「動的テーブル」の概念は以前に提案され、ストリームには追加モードと更新モードの2 つのモードが定義されていました。Flink はすでにストリームを動的テーブルに変換する追加モードをサポートしていますが、更新モードはまだサポートしていません。したがって、変更ログの解釈は、完全な動的テーブルの概念を得るために欠けているパズルのピースを埋めることです。もちろん、アップデートだけでなく、後で別途説明するリトラクトモードにも対応しています。
2.2、CDC ツールの選択
一般的な CDC スキームは次のように比較されます。
1.完璧な機能
CDC ツールには、現在、Debezium、Canal、およびその他の一般的なソリューションなど、多くのオプションがあります。現在、Debezium は Mysql、PG、SQL Server、Oracle、Cassandra、および Mongo をサポートしています。Flink が Debezium をサポートしている場合、Flink は以下に接続できることを意味します。スクリーンショットのすべてのデータベースの変更ログは、エコシステム全体を改善するのに役立ちます。その中でも、Debezium は完全 + 増分同期をサポートしています。これは非常に柔軟で、Exactly-Once を可能にします。
Debezium でサポートされているデータベースの種類は次のとおりです。
2. コミュニティを受け入れ、拡大を促進する
If you choose Debezium as the embedded engine of Flink, you can embed it into the code base as a dependency package instead of running through the kafka connector. また、MySQL サーバーと直接通信する必要もありません。複雑なスナップショット、GTID、ロックなどを処理する必要があります。利点。Debeziumコミュニティを受け入れ、協力しながら
第三に、内部データ構造は似ています
For the data structure RowData type inside Flink SQL, there are a metadata RowKind, which has 4 types, すなわち、挿入 (挿入), 更新 (更新前のUPDATE_BEFORE, 更新後のUPDATE_AFTER), および削除 (DELETE). これらの4つのデータ型は、基本的にBinlogの構造と一致しています。
Debezium のデータ構造における各メタデータ フィールドの意味の説明は次のとおりです。
· before フィールド: イベントが発生する前の状態を表すオプション フィールドです. create 操作の場合、このフィールドの値は null です。
· after フィールド: イベント発生後の行の状態を表すオプション フィールドです。削除操作の場合、このフィールドの値は null です。
· ソース: オフセット、binlog ファイル、データベース、テーブルなどのイベント メタ情報を含む必須フィールドです。
ts_ms: Debezium 処理イベントのタイムスタンプを表します
● OP フィールド: このフィールドにも、C (作成)、U (更新)、D (削除)、および読み取り® という 4 つの値があります。U 操作の場合、そのデータ部分には、Before と After の両方が含まれます。
3. コンセプト
ここには多くの概念が含まれます。誰もが最初に認識を持ち、後で分割して個別に説明します。
3.1、ストリーム
ストリームの概念は実際には簡単に理解できます **ストリームには、境界性と変化モードという 2 つの特徴があります。**次に、これら 2 つの機能を個別に紹介します。
- 変更モード:
上の図に示すように、追加モードと置換モード (アップサートとリトラクト) の2 つの動的テーブル モードがあります。次に、両者の違いを簡単に紹介します
追加モードの場合、理解しやすいです。テーブル定義で主キーが指定されていない場合、レコードがテーブルに追加されると、ストリーム レコードを新しい行としてテーブルに追加することによって更新または削除されることはありません。
置換モードでは、主キー キーがテーブルに定義されている場合、同じキー属性を持つレコードが存在しない場合はテーブルに挿入され、それ以外の場合は置換されます。次に、置換モードの場合、アップサート モードとリトラクト モードに分割されます。
Upsert モードの場合、Upsert (挿入と更新) と DELETE の 2 つのメッセージが含まれます。このモードと取り消しモードの主な違いは、UPDATE の変更が単一のメッセージでエンコードされることです。これはより効率的です。_
Retract モードの場合、更新ストリームには ADD および RETRACT メッセージが含まれます。Insert 変更の場合、ADD メッセージにエンコードされます。DELETE 変更の場合、RETRACT メッセージにエンコードされます。UPDATE 変更の場合、次のようになります。リトラクト メッセージと ADD メッセージとして Updated-Before にエンコードされます。このモードは、更新イベントのために 2 つのメッセージに分解する必要があり、効率は比較的低くなります。以下の図に示すように、リトレースメント フローとは何かを簡単に紹介します。
手術 |
ユーザー |
カウント(URL) |
マーク |
I(挿入) |
メアリー |
1 |
|
I(挿入) |
ボブ |
1 |
|
-U(更新前) |
メアリー |
0 |
レコードを削除します |
+U(更新後) |
メアリー |
2 |
|
I(挿入) |
リズ |
1 |
|
-U(更新前) |
ボブ |
0 |
レコードを削除します |
+U(更新後) |
ボブ |
2 |
- 境界性
制限付きストリーム: 制限付きサイズのイベントで構成され、ジョブ クエリは現在利用可能なデータを処理し、その後終了します。
制限のないストリーム: 無限のイベントで構成されます。入力が制限のないストリームの場合、クエリはすべてのデータが到着すると継続的に処理されます。
3. まとめ:
境界\変更モード |
追加 |
アップデート |
無制限 |
無制限のストリームを追加 例: Kafka ログ |
無制限ストリームの更新 たとえば、MySQL テーブルの変更を継続的にキャプチャする |
跳ねる |
制限付きストリームを追加 たとえば、HDFS の寄木細工のファイル、 MySQL テーブル |
制限付きストリームの更新 たとえば、特定の時点まで MySQL テーブルの変更をキャプチャする |
3.2、動的テーブル 動的テーブル
動的テーブルは、時間の経過とともに変化するテーブルであり、従来の通常のテーブルのようにクエリを実行できます。動的テーブルはストリームに変換でき、ストリームは動的テーブルに変換できます (スキーマが同じである必要があり、変換方法は、テーブル スキーマに主キーの定義が含まれているかどうかによって異なります)。注: Flink SQL で作成されたすべてのテーブルは動的テーブルです. 動的テーブルのクエリは新しい動的テーブルを生成します (入力に従って更新されます), クエリが終了するかどうかは入力の境界に依存します.
DynamicTable は概念的なオブジェクトであり、ストリームは物理的な表現です。
3.3、変更ログ
変更ログは、変更操作の列 (将来の挿入/削除フラグまたはそれ以上) と実際のメタデータ列を含む行で構成される追加ストリームです。Flink CDC の設計の目標は、変更ログのイベントを抽出し、それらを変更操作 (挿入、更新、削除イベントなど) に変換することです。
追加ストリームから更新ストリームに変換します (つまり、Interpret Changelog )。
更新ストリームから追加ストリームに変換します ( Emit Changelog )。
In Flink SQL, data flow from one operator to another in a form of Changelog Stream. 次の図に示すように、Changelog ストリームはいつでもテーブルまたはストリームに変換できます。
次の図は、ストリーム タイプとテーブルの間の変換を完全に示しています。
CDC ツールが異なれば、Changelog のエンコード方法も異なる場合があります。これは、flink の大きな課題でもあります。例として、Debezium と Canal の 2 つの一般的なソリューションを次に示します。
- Take Debezium as an example. Debezium は、Kafka Connector の上に構築された CDC ツールです。リアルタイムの変更ストリームを Kafka に送信できます。Debezium は、Kafka の変更ログ用に統一された形式を生成します。更新操作を例に挙げます。
{
"before": {
"id": 1004,
"first_name": "Anne",
"last_name": "Kretchmar",
"email": "[email protected]"
}, //before作为可选字段，如果是create操作，则该字段为null
"after": {
"id": 1004,
"first_name": "Anne Marie",
"last_name": "Kretchmar",
"email": "[email protected]"
}, //after作为可选字段，如果是delete操作，则该字段为null
"source": { ... },//强制字段，标识事件元信息，如offset,binlog file，database,table 等等。
"op": "u", //强制字段，用来描述操作类型，如C(create),U(update),D(delete)
"ts_ms": 1465581029523
}
デフォルトでは、Debezium は削除操作に対して 2 つのイベントを出力します: DELETE イベントと廃棄 (tombstone) イベント (null 値/ペイロード)。廃棄イベントは Kafka 圧縮メカニズムに使用されます。Debezium はストレージ システムではありませんが、JSON 形式に基づくストレージ形式を表し、逆シリアル化された結果行を ChangeRow または Tuple2<Boolean, Row> に変換できます。
- Canal は中国で人気のある CDC ツールです. Mysql から他のシステムへの変更をキャプチャするために使用されます. JSON 形式と protobuf 形式の Kafka と RocketMQ ストリームの変更をサポートしています. 更新操作の例を次に示します:
{
"data": [
{//表示真实的数据，如果是更新操作，则是更新后的状态，如果是删除操作，则是删除之前的状态。
"id": "13",
"username": "13",
"password": "6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9",
"name": "Canal Manager V2"
}
],
"old": [ //可选字段，如果不是update操作，那么该字段为null
{
"id": "13",
"username": "13",
"password": "6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9",
"name": "Canal Manager"
}
],
"database": "canal_manager",
"es": 1568972368000,
"id": 11,
"isDdl": false,
"mysqlType": {...},
"pkNames": [
"id"
],
"sql": "",
"sqlType": {...},
"table": "canal_user",
"ts": 1568972369005,
"type": "UPDATE"
}
Flink は、format="canal-json" または format="debezium-json" を介して渡すことができる、これら 2 つの主流の CDC ツール エンコーディング フォーマットの両方をサポートします。
4. ソースコードのトレーサビリティ
上記のセクションから、Flink が CDC を実装するための組み込みエンジンとして Debezium を選択したことが言及されています. 現在、Flink CDC でサポートされているコネクタは次のとおりです:
注: Mongo のコネクタ サポートは、Flink CDC2.0 バージョンで使用する必要があります。
データベース |
バージョン |
MySQL |
データベース: 5.7、8.0.xJDBC ドライバー: 8.0.16 |
PostgreSQL |
データベース: 9.6、10、11、12JDBC ドライバー: 42.2.12 |
モンゴDB |
データベース: 4.0、4.2、5.0MongoDB ドライバー: 4.3.1 |
Flink CDC コネクタに対応する Flink のバージョンは次のとおりです。
Flink CDC コネクタのバージョン |
フリンクバージョン |
1.0.0 |
1.11.* |
1.1.0 |
1.11.* |
1.2.0 |
1.12.* |
1.3.0 |
1.12.* |
1.4.0 |
1.13.* |
2.0.0 |
1.13.* |
4.1、デベジウム-Mysql
Flink が Debezium とどのように結合するか、および特定の対話プロセスについて詳しく学ぶ前に、Debezium がイベント変更キャプチャを実装する方法を簡単に見てみましょう。以下の図は、CDC リンク全体における Debezium の役割 (例として Debezium1.2 バージョンを取り上げます) を示しています。
Mysql を例にとると、Debezium を使用する前に、次の作業を準備する必要があります。
4.1.0、準備
1. mysql アカウントを承認する必要があります
GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user' IDENTIFIED BY 'password';
2.Mysqlバイナリログを開く
-- 1、检查是否已经开启
SELECT variable_value as "BINARY LOGGING STATUS (log-bin) ::"
FROM information_schema.global_variables WHERE variable_name='log_bin';
--2、配置服务文件，开启binlog
server-id = 223344
log_bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
expire_logs_days = 10
3.GTID を有効にする
グローバル トランザクション識別子 (GTID) は、クラスター内のサーバーで発生するトランザクションを一意に識別します。Debezium MySQL Connector では必要ありませんが、GTID を使用すると、レプリケーションが簡素化され、マスター サーバーとスレーブ サーバーが一致しているかどうかを確認しやすくなります。
-- 1、开启gtid_mode
gtid_mode=ON
--2、开启enforce_gtid_consistency
enforce_gtid_consistency=ON
--3、检测是否生效
show global variables like '%GTID%';
4.1.1、データベース スナップショットの実行 (全読み取り)
Mysql Connector が初めて開始されると、最初にデータベースの一貫性のある初期スナップショットが実行されます. 主な理由は、Mysql は通常、一定期間後にバイナリログをクリアするように設定されているためです.一度、最初にスナップショットを撮ります。デフォルトのスナップショット モードは inital で、snapshot.mode パラメータで調整できます。次に、特定のスナップショットの詳細を確認します。
-
最初にグローバル読み取りロックを取得して、他のクライアントの書き込みをブロックします (グローバル ロックが許可されていないことを Debezium が検出すると、テーブル レベルのロックに変更されます) スナップショット自体は、他のクライアントが DDL を実行するのを防ぐことはできないことに注意してください。 . これは、バイナリログの場所とテーブル スキーマを読み取ろうとするコネクタに干渉する可能性があるためです。バイナリログの場所の読み取り中にグローバル読み取りロックが保持され、後の手順で解放されます。
-
反復可能な読み取りトランザクションを開始して、後続のすべての読み取りが一貫したスナップショットに対して行われるようにします。
-
現在のバイナリログの場所を読み取ります。
-
Connecto 構成で許可されているライブラリ テーブルに対応するスキーマを読み取ります。
-
グローバル読み取りロック/テーブル レベル ロックを解放すると、この時点で他のクライアントが書き込み可能になります。
-
DDL 変更ステートメントを対応するトピックに書き込みます (これは、すべての DDL ステートメントを保存するための一貫性を確保するためでもあります。コネクタがクラッシュまたは正常に停止された後に再起動すると、すべての DDL ステートメントをこのトピックから読み取って、特定の場所でテーブル構造を再構築できます)。スキーマの不一致による例外の発生を防ぐために、バイナリログ内のクラッシュ前の時点まで)。
-
ライブラリ テーブルをスキャンし、特定のテーブルのトピックに関する各行のイベントを生成します。
-
トランザクションをコミットし、完了したスナップショットをコネクタ オフセットに記録します。
If the Connector fails while making a snapshot, it will create a new snapshot when it restarts. スナップショットが完了すると、binlog の同じ場所から読み取りが開始されるため、変更イベントが失われることはありません。コネクタが長時間停止し、MySQL サーバーが古い binlog ファイルをパージすると、コネクタの最後の位置が失われる可能性があります。コネクターが再始動すると、MySQL サーバーには開始点がなくなり、コネクターは別の初期スナップショットを実行します。
4.1.2. 増分読み取り
-
Binlog クライアントを初期化し、binlog-client という名前のスレッドを開始します
-
クライアントはイベント リスナーを登録します。これは、主にオフセットの更新、イベント処理の転送、ハートビート通知、およびその他のロジックのために、handleEvent メソッドを呼び出します。 max_binlog_size が設定されている場合、binlog の位置がリセットされます。
-
削除、更新、挿入イベントなどのさまざまなイベント タイプに従って解析する一連のデシリアライザーを構成します。次に、handleDelete、handleUpdate、handleInsert などのイベント ハンドラーが呼び出されて処理されます。
-
イベントが検出されると、特定のイベント タイプに応じて特定のプロセッサが呼び出されますが、ここでは説明しません。この記事では主に、flink がデータのこの部分を受け取り、サポートするデータ構造を変換する方法について説明します。
4.2、Flink-cdc-mysql
Flink が Debezium エンジンを呼び出す方法を紹介する別の記事があります。ここでは最初に呼び出し関係図を示します。読者は時間があるときに自分でそれを読むことができます
4.3、Debezium-Mysql のプロパティ
The following table is the configuration file that comes with debezium. It can still reuse in flink cdc. 有効にする前にプレフィックス "debezium." を追加するだけで済みます.
財産 |
デフォルト |
説明 |
名前 |
コネクタの一意の名前。名前が同じ場合、失敗してエラーが報告されます |
|
コネクタ.クラス |
コネクタ コネクタのロード クラス。Mysql コネクタには io.debezium.connector.mysql.MySqlConnector を使用します。 |
|
タスク.最大 |
1 |
コネクタによって作成されるタスクの最大数。mysql には 1 つのタスクのみが使用されます。 |
データベース.ホスト名 |
Mysql データベース アドレス |
|
データベース.ポート |
3306 |
Mysql データベース ポート |
データベース.ユーザー |
Mysql データベース認証ユーザー名 |
|
データベース.パスワード |
Mysql データベース認証パスワード |
|
データベース.サーバー名 |
Mysql サービス名 |
|
データベース.サーバー.id |
ランダム |
Mysql サービス ID |
database.history.kafka.topic |
データベース テーブルの履歴スキーマを格納するトピック |
|
database.history.kafka.bootstrap.servers |
データベース テーブルの履歴スキーマが保存されているカフカ アドレス |
|
データベース.ホワイトリスト |
空の文字列 |
一个可选的逗号分隔的正则表达式列表，与要监控的数据库名称相匹配；任何不包括在白名单中的数据库名称将被排除在监控之外。默认情况下，所有数据库都将被监控。不能与database.blacklist一起使用 |
database.blacklist |
empty string |
一个可选的逗号分隔的正则表达式列表，与数据库名称相匹配，以排除在监控之外；任何不包括在黑名单中的数据库名称将被监控。不能与database.whitelist一起使用 |
table.whitelist |
empty string |
一个可选的逗号分隔的正则表达式列表，用于匹配要监控的表的全称表标识符；任何不包括在白名单中的表将被排除在监控之外。每个标识符的形式是databaseName.tableName。默认情况下，连接器将监控每个被监控数据库中的每个非系统表。不能与table.blacklist一起使用 |
table.blacklist |
empty string |
一个可选的逗号分隔的正则表达式列表，用于匹配要从监控中排除的表的全称表标识符；任何不包括在黑名单中的表都将被监控。每个标识符的形式是databaseName.tableName。不能与table.whitelist一起使用 |
column.blacklist |
empty string |
一个可选的逗号分隔的正则表达式列表，该列表与应从更改事件消息值中排除的列的全称名称相匹配。列的全称是数据库名.表名.列名，或者数据库名.模式名.表名.列名 |
column.truncate.to.length.chars |
n/a |
一个可选的逗号分隔的正则表达式列表，它与基于字符的列的完全限定名称相匹配，如果字段值长于指定的字符数，其值应在变更事件消息值中被截断。在一个配置中可以使用具有不同长度的多个属性，尽管在每个属性中长度必须是一个正整数。列的全称是数据库名.表名.列名的形式 |
column.mask.with.length.chars |
n/a |
当列长度超过指定长度，那么多余的值由*来替换 |
column.mask.hash.hashAlgorithm.with.salt.salt |
n/a |
列加盐操作 |
time.precision.mode |
adaptive_time_microseconds |
时间、日期和时间戳可以用不同种类的精度表示，包括。adaptive_time_microseconds（默认）根据数据库列的类型，使用毫秒、微秒或纳秒的精度值，准确捕获日期、数据时间和时间戳的值，但TIME类型的字段除外，它总是被捕获为微秒。adaptive（已弃用）根据数据库列的类型，使用毫秒、微秒或纳秒的精度，完全按照数据库中的时间和时间戳值来捕捉；或者connector总是使用Kafka Connector内置的时间、日期和时间戳的表示法来表示时间和时间戳值，它使用毫秒精度，而不管数据库列的精度 |
decimal.handling.mode |
precise |
指定连接器应该如何处理DECIMAL和NUMERIC列的值：precision（默认）使用java.math.BigDecimal值精确表示它们，在变化事件中以二进制形式表示；或者使用double值表示它们，这可能会导致精度的损失，但会更容易使用。 string选项将值编码为格式化的字符串，这很容易使用，但会失去关于真正类型的语义信息 |
bigint.unsigned.handling.mode |
long |
指定BIGINT UNSIGNED列在变化事件中的表示方式，包括：precision使用java.math.BigDecimal表示数值，在变化事件中使用二进制表示法和Kafka Connect的org.apache.kafka.connect.data.Decimal类型进行编码； long（默认）使用Java的long表示数值，它可能不提供精度，但在消费者中使用起来会容易得多。只有在处理大于2^63的值时，才应该使用精确设置，因为这些值不能用long来表达。 |
include.schema.changes |
true |
指定是否要将数据库schema变更事件推送到Topic中 |
include.query |
false |
指定连接器是否应包括产生变化事件的原始SQL查询。 注意：这个选项要求MySQL在配置时将binlog_rows_query_log_events选项设置为ON。查询将不会出现在从快照过程中产生的事件中。 启用该选项可能会暴露出被明确列入黑名单的表或字段，或通过在变更事件中包括原始SQL语句而被掩盖。出于这个原因，这个选项默认为 "false" |
event.processing.failure.handling.mode |
fail |
指定connector在反序列化binlog事件过程中对异常的反应。 fail表示将传播异常，停止Connector Warn将记录有问题的事件及binlog偏移量，然后跳过 skip:直接跳过有问题的事件 |
inconsistent.schema.handling.mode |
fail |
指定连接器应该如何应对与内部Schema表示中不存在的表有关的binlog事件（即内部表示与数据库不一致）。 fail将抛出一个异常（指出有问题的事件及其binlog偏移），并停止连接器。 warn将跳过有问题的事件，并把有问题事件和它的binlog偏移量记录下来。 skip将跳过有问题的事件。 |
max.queue.size |
8192 |
指定阻塞队列的最大长度，从数据库日志中读取的变更事件在写入Kafka之前会被放入该队列。这个队列可以为binlog reader提供反向压力，例如，当写到Kafka的速度较慢或Kafka不可用时。出现在队列中的事件不包括在这个连接器定期记录的偏移量中。默认为8192，并且应该总是大于max.batch.size属性中指定的最大批次大小。 |
max.batch.size |
2048 |
指定在该连接器的每次迭代中应处理的每批事件的最大长度。默认值为2048 |
poll.interval.ms |
1000 |
指定连接器在每次迭代过程中等待新的变化事件出现的毫秒数。默认为1000毫秒，或1秒 |
connect.timeout.ms |
30000 |
指定该连接器在尝试连接到MySQL数据库服务器后，在超时前应等待的最大时间（毫秒）。默认值为30秒 |
tombstones.on.delete |
true |
控制是否应在删除事件后生成墓碑事件。 当为真时，删除操作由一个删除事件和一个后续的墓碑事件表示。当false时，只有一个删除事件被发送。 发出墓碑事件（默认行为）允许Kafka在源记录被删除后完全删除所有与给定键有关的事件。 |
message.key.columns |
empty string |
一个分号的正则表达式列表，匹配完全限定的表和列，以映射一个主键。 每一项（正则表达式）必须与代表自定义键的<完全限定的表>：<列的逗号分隔列表>相匹配。 完全限定的表可以定义为databaseName.tableName。 |
binary.handling.mode |
bytes |
指定二进制（blob、binary、varbinary等）列在变化事件中的表示方式，包括：bytes表示二进制数据为字节数组（默认），base64表示二进制数据为base64编码的String，hex表示二进制数据为hex编码的（base16）String |
connect.keep.alive |
true |
指定是否应使用单独的线程来确保与MySQL服务器/集群保持连接 |
table.ignore.builtin |
true |
指定是否应该忽略内置系统表。无论表的白名单或黑名单如何，这都适用。默认情况下，系统表被排除在监控之外，当对任何系统表进行更改时，不会产生任何事件。 |
database.history.kafka.recovery.poll.interval.ms |
100 |
用于指定连接器在启动/恢复期间轮询持久数据时应等待的最大毫秒数。默认值是100ms |
database.history.kafka.recovery.attempts |
4 |
在连接器恢复之前，连接器尝试读取持久化历史数据的最大次数。没有收到数据后的最大等待时间是recovery.attempts x recovery.poll.interval.ms |
database.history.skip.unparseable.ddl |
false |
指定连接器是否应该忽略畸形或未知的数据库语句，或停止处理并让操作者修复问题。安全的默认值是false。跳过应该谨慎使用，因为在处理binlog时，它可能导致数据丢失或混乱 |
database.history.store.only.monitored.tables.ddl |
false |
指定连接器是否应该记录所有的DDL语句或（当为true时）只记录那些与Debezium监控的表有关的语句（通过过滤器配置）。安全的默认值是false。这个功能应该谨慎使用，因为当过滤器被改变时，可能需要缺失的数据。 |
database.ssl.mode |
disabled |
指定是否使用加密的连接。默认是disabled，并指定使用未加密的连接。 如果服务器支持安全连接，preferred选项会建立一个加密连接，否则会退回到未加密连接。 required选项建立一个加密连接，但如果由于任何原因不能建立加密连接，则会失败。 verify_ca选项的行为类似于required，但是它还会根据配置的证书颁发机构（CA）证书来验证服务器的TLS证书，如果它不匹配任何有效的CA证书，则会失败。 verify_identity选项的行为与verify_ca类似，但另外验证服务器证书与远程连接的主机是否匹配。 |
binlog.buffer.size |
0 |
Binlog Reader使用的缓冲区的大小。 在特定条件下，MySQL Binlog可能包含Roldback语句完成的未提交的数据。典型示例正在使用SavePoints或混合单个事务中的临时和常规表更改。 当检测到事务的开始时，Debezium尝试向前滚动Binlog位置并找到提交或回滚，以便决定事务的更改是否会流流。缓冲区的大小定义了Debezium可以在搜索事务边界的同时的交易中的最大变化次数。如果事务的大小大于缓冲区，则Debezium需要重新卷起并重新读取流式传输时不适合缓冲区的事件。0代表禁用缓冲。默认情况下禁用。 注意：此功能还在测试 |
snapshot.mode |
initial |
指定连接器在启动允许快照时的模式。默认为inital，并指定仅在没有为逻辑服务器名称记录偏移时才能运行快照。 when_needed选项指定在启动时运行快照，只要它认为它需要（当没有可用偏移时，或者以前记录的偏移量在指定服务器中不可用的Binlog位置或GTID）。 never选项指定不运行快照。 schema_only选项只获取启动以来的更改。 schema_only_recovery选项是现有连接器的恢复选项，用来恢复损坏或者丢失的数据库历史topic |
snapshot.locking.mode |
minimal |
控制连接器是否持续获取全局MySQL读取锁（防止数据库的任何更新）执行快照。有三种可能的值minimal，extended，none。 minimal仅在连接器读取数据库模式和其他元数据时保持全局读取锁定仅适用于快照的初始部分。快照中的剩余工作涉及从每个表中选择所有行，即使在不再保持全局读取锁定状态时，也可以使用可重复读取事务以一致的方式完成。虽然其他MySQL客户端正在更新数据库。 extended指在某些情况下客户端提交MySQL从可重复读取语义中排除的操作，可能需要阻止所有写入的全部持续时间。 None将阻止连接器在快照过程中获取任何表锁。此值可以与所有快照模式一起使用，但仅在快照时不发生Schema更改时，才能使用。注意:对于使用MyISAM引擎定义的表，表仍将被锁定，只要该属性设置为MyISAM获取表锁定。InnoDB引擎获取的是行级锁 |
snapshot.select.statement.overrides |
控制哪些表的行将被包含在快照中。此属性包含一个以逗号分隔的完全限定的表（DB_NAME.TABLE_NAME）的列表。单个表的选择语句在进一步的配置属性中指定，每个表由 id snapshot.select.statement.overrides.[DB_NAME].[TABLE_NAME] 识别。这些属性的值是在快照期间从特定表检索数据时要使用的 SELECT 语句。对于大型的仅有附录的表来说，一个可能的用例是设置一个特定的点来开始（恢复）快照，以防止之前的快照被打断。 注意：这个设置只对快照有影响。从binlog捕获的事件完全不受其影响。 |
|
min.row.count.to.stream.results |
1000 |
在快照操作中，连接器将查询每个包含的表，为该表的所有行产生一个读取事件。这个参数决定了MySQL连接是否会将表的所有结果拉入内存，或者是否会将结果流化（可能会慢一些，但对于非常大的表来说是可行的）。该值指定了在连接器将结果流化之前，表必须包含的最小行数，默认为1000。将此参数设置为'0'，可以跳过所有的表大小检查，并在快照期间始终流式处理所有结果 |
database.initial.statements |
建立到数据库的 JDBC 连接（不是事务日志读取连接）时要执行的 SQL 语句的分号分隔列表。使用双分号 (';;') 将分号用作字符而不是分隔符。注意：连接器可以自行决定建立 JDBC 连接，因此这通常仅用于配置会话参数，而不用于执行 DML 语句 |
|
snapshot.delay.ms |
连接器在启动后，进行快照之前需要等待的时间间隔；当在集群中启动多个连接器时可以避免快照中断 |
|
snapshot.fetch.size |
指定在快照时应该从表中一次性读取的最大行数 |
|
snapshot.lock.timeout.ms |
10000 |
指定在快照时等待获取表锁的最长时间，如果在指定时间间隔内未获取到表锁的时候，则快照失败 |
enable.time.adjuster |
MySQL では、ユーザーは年の値を 2 桁または 4 桁として挿入できます。2 桁の場合、値は 1970 ～ 2069 の範囲に自動的にマップされます。これは通常、データベースによって行われます。Debezium が変換を行う場合は true (デフォルト) に設定します。 変換がデータベースに完全に委任されている場合は false に設定します |
|
sanitize.field.names |
コネクタ構成で、Avro を使用するように key.converter または value.converter パラメーターを明示的に指定する場合は true、それ以外の場合はデフォルトで false になります。 |
Avro 命名要件に準拠するためにフィールド名をサニタイズするかどうか |
スキップされた操作 |
スキップする op 操作のコンマ区切りリスト。操作には、挿入の場合は c、更新の場合は u、削除の場合は d が含まれます。デフォルトでは、アクションはスキップされません |