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

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

DDL許可リスト

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

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

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

DDL レプリケーションに関する考慮事項

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

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

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

変更フィードの構成ファイルが次のとおりであると仮定します。

[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 をサポートしていません。以下は一例です。

変更フィードの構成ファイルが次のとおりであると仮定します。

[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 は 1 つの DDL ステートメント内でtest.t1test.t3の名前を交換しますが、TiCDC はこれを正しく処理できません。この場合は、エラーメッセージを参照して対処してください。

SQLモード

デフォルトでは、TiCDC は TiDB のデフォルト SQL モードを使用して DDL ステートメントを解析します。アップストリーム TiDB クラスターがデフォルト以外の SQL モードを使用する場合は、TiCDC 構成ファイルで SQL モードを指定する必要があります。そうしないと、TiCDC が DDL ステートメントを正しく解析できない可能性があります。 TiDB SQLモードの詳細については、 SQLモードを参照してください。

たとえば、アップストリーム TiDB クラスターがANSI_QUOTESモードを使用する場合は、changefeed 構成ファイルで次のように SQL モードを指定する必要があります。

# In the value, "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" is the default SQL mode of TiDB. # "ANSI_QUOTES" is the SQL mode added to your upstream TiDB cluster. sql-mode = "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ANSI_QUOTES"

SQL モードが構成されていない場合、TiCDC は一部の DDL ステートメントを正しく解析できない可能性があります。例えば:

CREATE TABLE "t1" ("a" int PRIMARY KEY);

TiDB のデフォルト SQL モードでは、二重引用符が識別子ではなく文字列として扱われるため、TiCDC は DDL ステートメントを正しく解析できません。

したがって、レプリケーション タスクを作成するときは、構成ファイルで上流の TiDB クラスターによって使用される SQL モードを指定することをお勧めします。

このページは役に立ちましたか?