チェンジフィード DDL レプリケーション
このドキュメントでは、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 | 複製するかどうか | 取り扱い理由 |
|---|---|---|
RENAME TABLE test.t1 TO test.t2 | 複製する | test.t1フィルタルールに一致します |
RENAME TABLE test.t1 TO ignore.t1 | 複製する | test.t1フィルタルールに一致します |
RENAME TABLE ignore.t1 TO ignore.t2 | 無視する | ignore.t1フィルタルールに一致しません |
RENAME TABLE test.n1 TO test.t1 | エラーを報告してレプリケーションを終了する | 古いテーブル名test.n1フィルタルールに一致しませんが、新しいテーブル名test.t1フィルタルールに一致します。この操作は不正です。この場合、エラーメッセージを参照して対処してください。 |
RENAME TABLE ignore.t1 TO test.t1 | エラーを報告してレプリケーションを終了する | 上記と同じ理由です。 |
DDL ステートメントで複数のテーブルの名前を変更する
DDL ステートメントで複数のテーブルの名前を変更する場合、TiCDC は、古いデータベース名、古いテーブル名、および新しいデータベース名がすべてフィルター ルールに一致する場合にのみ、DDL ステートメントを複製します。
また、TiCDCはテーブル名を入れ替えるRENAME TABLE DDLをサポートしていません。以下に例を示します。
changefeed の構成ファイルが次のようになっていると仮定します。
[filter]
rules = ['test.t*']
TiCDC はこのタイプの DDL を次のように処理します。
| DDL | 複製するかどうか | 取り扱い理由 |
|---|---|---|
RENAME TABLE test.t1 TO test.t2, test.t3 TO test.t4 | 複製する | すべてのデータベース名とテーブル名はフィルター ルールに一致します。 |
RENAME TABLE test.t1 TO test.ignore1, test.t3 TO test.ignore2 | 複製する | 古いデータベース名、古いテーブル名、および新しいデータベース名は、フィルター ルールと一致します。 |
RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22; | エラーを報告する | 新しいデータベース名ignoreフィルター ルールと一致しません。 |
RENAME TABLE test.t1 TO test.t4, test.t3 TO test.t1, test.t4 TO test.t3; | エラーを報告する | RENAME TABLE DDL文では、 test.t1とtest.t3名前が1つのDDL文内で入れ替わっていますが、TiCDCはこれを正しく処理できません。この場合、エラーメッセージを参照して対処してください。 |
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*']
[[filter.event-filters]]
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 | DDLの動作 | DMLの動作 | 説明 |
|---|---|---|---|
CREATE TABLE test.t1 (id INT, name VARCHAR(50)); | 無視する | 複製する | test.t1イベントフィルタルールに一致するため、 CREATE TABLEイベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 |
CREATE TABLE test.t2 (id INT, name VARCHAR(50)); | 複製する | 複製する | test.t2はイベント フィルタ ルールと一致しません。 |
CREATE TABLE test.ignore (id INT, name VARCHAR(50)); | 無視する | 無視する | test.ignoreイベント フィルタ ルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 |
DROP TABLE test.t1; | 無視する | test.t1イベントフィルタルールに一致するため、イベントDROP TABLE無視されます。テーブルが削除されたため、TiCDC はt1の DML イベントを複製しなくなります。 | |
TRUNCATE TABLE test.t1; | 無視する | 複製する | test.t1イベントフィルタルールに一致するため、 TRUNCATE TABLEイベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 |
RENAME TABLE test.t1 TO test.t2; | 無視する | 複製する | test.t1イベントフィルタルールに一致するため、 RENAME TABLEイベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 |
RENAME TABLE test.t1 TO test.ignore; | 無視する | 無視する | test.t1イベント フィルター ルールに一致するため、 RENAME TABLEイベントは無視されます。4 test.ignoreイベント フィルター ルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 |
注記：
- データベースにデータをレプリケーションする際は、イベントフィルターを使用してDDLイベントを慎重にフィルタリングしてください。レプリケーション中は、上流と下流のデータベーススキーマの整合性が維持されていることを確認してください。整合性が維持されていない場合、TiCDCはエラーを報告したり、未定義のレプリケーション動作を引き起こしたりする可能性があります。
- v6.5.8、v7.1.4、v7.5.1より前のバージョンでは、イベントフィルタを使用してテーブルの作成または削除を含むDDLイベントをフィルタリングすると、DMLレプリケーションに影響します。これらのバージョンではこの機能の使用は推奨されません。