チェンジフィード DDL レプリケーション

4 Contributors

このドキュメントでは、TiCDC での DDL レプリケーションのルールと特殊なケースについて説明します。

DDL 許可リスト

現在、TiCDC は許可リストを使用して、DDL ステートメントをレプリケートするかどうかを決定します。許可リスト内の DDL ステートメントのみがダウンストリームにレプリケートされます。許可リストにない DDL ステートメントはレプリケートされません。

TiCDC でサポートされている DDL ステートメントの許可リストは次のとおりです。

• データベースを作成する
• データベースを削除
• テーブルを作成する
• ドロップテーブル
• 列を追加
• ドロップ列
• インデックスの作成 / インデックスの追加
• インデックスを削除
• テーブルを切り捨てる
• 列を変更する
• テーブル名の変更
• 列のデフォルト値を変更する
• テーブルコメントの変更
• インデックス名の変更
• パーティションを追加
• パーティションを削除する
• パーティションを切り捨てる
• ビューを作成
• ドロップビュー
• テーブル文字セットを変更する
• データベースの文字セットを変更する
• テーブルを回復する
• 主キーを追加する
• 主キーを削除する
• 自動 ID をリベースする
• テーブルインデックスの可視性を変更する
• 交換パーティション
• パーティションを再編成する
• テーブルTTLを変更する
• テーブルを変更してTTLを削除

DDLレプリケーションの考慮事項

ADD INDEXおよびCREATE INDEX DDL の非同期実行

ダウンストリームが TiDB の場合、TiCDC はADD INDEXおよびCREATE INDEX DDL 操作を非同期で実行し、変更フィード レプリケーションの待機レイテンシーへの影響を最小限に抑えます。つまり、 ADD INDEXおよびCREATE INDEX DDL をダウンストリーム TiDB に複製して実行した後、TiCDC は DDL 実行の完了を待たずにすぐに戻ります。これにより、後続の DML 実行がブロックされることが回避されます。

ダウンストリームでADD INDEXまたはCREATE INDEX DDL 操作を実行中に、TiCDC が同じテーブルの次の DDL 操作を実行すると、この DDL 操作がqueueing状態で長時間ブロックされる可能性があります。これにより、TiCDC がこの DDL 操作を繰り返し実行することになり、再試行に時間がかかりすぎると、レプリケーション タスクが失敗する可能性があります。v8.1.2 以降では、TiCDC がダウンストリーム データベースのSUPER権限を持っている場合、定期的にADMIN SHOW DDL JOBS実行して、非同期で実行された DDL タスクのステータスを確認します。TiCDC は、レプリケーションを続行する前に、インデックス作成が完了するまで待機します。これにより、レプリケーションのレイテンシーが長くなる可能性がありますが、レプリケーション タスクの失敗を回避できます。

注記：

• 特定のダウンストリーム DML の実行がレプリケーションが完了していないインデックスに依存している場合、これらの DML の実行が遅くなり、TiCDC レプリケーションのレイテンシーに影響する可能性があります。
• DDL をダウンストリームにレプリケートする前に、TiCDC ノードがクラッシュした場合、またはダウンストリームが他の書き込み操作を実行している場合、DDL レプリケーションが失敗する可能性は非常に低くなります。ダウンストリームをチェックして、それが発生するかどうかを確認できます。

テーブル名の変更に関する DDL レプリケーションの考慮事項

レプリケーション プロセス中に一部のコンテキストが不足しているため、TiCDC ではRENAME TABLE DDL のレプリケーションにいくつかの制約があります。

DDL ステートメントで単一のテーブルの名前を変更する

DDL ステートメントが単一のテーブルの名前を変更する場合、TiCDC は古いテーブル名がフィルター ルールと一致する場合にのみ DDL ステートメントを複製します。次に例を示します。

changefeed の構成ファイルが次のようになっていると仮定します。

[filter]
rules = ['test.t*']

TiCDC はこのタイプの DDL を次のように処理します。

DDL ステートメントで複数のテーブルの名前を変更する

DDL ステートメントで複数のテーブルの名前を変更する場合、TiCDC は、古いデータベース名、古いテーブル名、および新しいデータベース名がすべてフィルター ルールに一致する場合にのみ、DDL ステートメントを複製します。

また、TiCDC はテーブル名を入れ替えるRENAME TABLE DDL をサポートしていません。以下は例です。

changefeed の構成ファイルが次のようになっていると仮定します。

[filter]
rules = ['test.t*']

TiCDC はこのタイプの DDL を次のように処理します。

DDL ステートメントの考慮事項

アップストリームでクロスデータベース DDL ステートメント ( CREATE TABLE db1.t1 LIKE t2など) を実行する場合は、関連するすべてのデータベース名を DDL ステートメント ( CREATE TABLE db1.t1 LIKE db2.t2など) で明示的に指定することをお勧めします。そうしないと、データベース名情報が不足しているため、ダウンストリームでクロスデータベース DDL ステートメントが正しく実行されない可能性があります。

イベント フィルタ ルールを使用して DDL イベントをフィルタする場合の注意事項

フィルターされた DDL ステートメントにテーブルの作成または削除が含まれる場合、TiCDC は DML ステートメントのレプリケーション動作に影響を与えずに DDL ステートメントのみをフィルターします。次に例を示します。

changefeed の構成ファイルが次のようになっていると仮定します。

[filter]
rules = ['test.t*']

matcher = ["test.t1"] # This filter rule applies only to the t1 table in the test database.
ignore-event = ["create table", "drop table", "truncate table", "rename table"]

注記：

• データをデータベースにレプリケートする場合は、イベント フィルターを使用して DDL イベントを慎重にフィルター処理します。レプリケーション中に上流と下流のデータベース スキーマが一貫していることを確認してください。そうでない場合、TiCDC はエラーを報告したり、未定義のレプリケーション動作を引き起こしたりする可能性があります。
• v6.5.8、v7.1.4、v7.5.1 より前のバージョンでは、イベント フィルターを使用してテーブルの作成または削除を含む DDL イベントをフィルターすると、DML レプリケーションに影響します。これらのバージョンではこの機能を使用することはお勧めしません。