TiCDCのFAQ

このドキュメントでは、TiCDCを使用するときに発生する可能性のある一般的な質問を紹介します。

ノート：

このドキュメントでは、 cdc cliコマンドで指定されたPDアドレスは--pd=http://10.0.10.25:2379です。コマンドを使用するときは、アドレスを実際のPDアドレスに置き換えてください。

TiCDCでタスクを作成するときにstart-tsを選択するにはどうすればよいですか？

レプリケーションタスクのstart-tsは、アップストリームTiDBクラスタのタイムスタンプOracle（TSO）に対応します。 TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクのstart-tsは、次の要件を満たす必要があります。

• start-tsの値は、現在のTiDBクラスタのtikv_gc_safe_pointの値よりも大きくなります。そうしないと、タスクの作成時にエラーが発生します。
• タスクを開始する前に、ダウンストリームにstart-tsより前のすべてのデータがあることを確認してください。メッセージキューへのデータの複製などのシナリオで、アップストリームとダウンストリーム間のデータの整合性が必要ない場合は、アプリケーションのニーズに応じてこの要件を緩和できます。

start-tsを指定しない場合、またはstart-tsを0として指定する場合、レプリケーションタスクの開始時に、TiCDCは現在のTSOを取得し、このTSOからタスクを開始します。

TiCDCでタスクを作成するときに、一部のテーブルを複製できないのはなぜですか？

cdc cli changefeed createを実行してレプリケーションタスクを作成すると、TiCDCはアップストリームテーブルがレプリケーションの制限を満たしているかどうかを確認します。一部のテーブルが制限を満たしていない場合、不適格なテーブルのリストとともにsome tables are not eligible to replicateが返されます。 Yまたはyを選択してタスクの作成を続行でき、これらのテーブルのすべての更新はレプリケーション中に自動的に無視されます。 Yまたはy以外の入力を選択した場合、レプリケーションタスクは作成されません。

TiCDCレプリケーションタスクの状態を表示するにはどうすればよいですか？

TiCDCレプリケーションタスクのステータスを表示するには、 cdc cliを使用します。例えば：

cdc cli changefeed list --pd=http://10.0.10.25:2379

期待される出力は次のとおりです。

[{
    "id": "4e24dde6-53c1-40b6-badf-63620e4940dc",
    "summary": {
      "state": "normal",
      "tso": 417886179132964865,
      "checkpoint": "2020-07-07 16:07:44.881",
      "error": null
    }
}]

• checkpoint ：TiCDCは、このタイムスタンプより前のすべてのデータをダウンストリームに複製しました。
• state ：このレプリケーションタスクの状態：
  • normal ：タスクは正常に実行されます。
  • stopped ：タスクが手動で停止されたか、エラーが発生しました。
  • removed ：タスクは削除されます。

ノート：

この機能はTiCDC4.0.3で導入されました。

TiCDC gc-ttlとは何ですか？

v4.0.0-rc.1以降、PDはサービスレベルのGCセーフポイントの設定で外部サービスをサポートします。どのサービスでも、GCセーフポイントを登録および更新できます。 PDは、このGCセーフポイントより後のキー値データがGCによってクリーンアップされないようにします。

レプリケーションタスクが使用できないか中断されている場合、この機能により、TiCDCによって消費されるデータがGCによってクリーンアップされることなくTiKVに保持されます。

TiCDCサーバーを起動するときに、 gc-ttlを構成することにより、GCセーフポイントの存続時間（TTL）期間を指定できます。 gc-ttlもできTiUPを使用して変更する 。デフォルト値は24時間です。 TiCDCでは、この値は次のことを意味します。

• TiCDCサービスが停止した後、GCセーフポイントがPDに保持される最大時間。
• タスクが中断または手動で停止された後、レプリケーションタスクを一時停止できる最大時間。中断されたレプリケーションタスクの時間がgc-ttlで設定された値より長い場合、レプリケーションタスクはfailedステータスになり、再開できず、GCセーフポイントの進行に影響を与え続けることができません。

上記の2番目の動作は、TiCDCv4.0.13以降のバージョンで導入されています。目的は、TiCDCのレプリケーションタスクが長時間中断され、アップストリームTiKVクラスタのGCセーフポイントが長時間継続せず、古いデータバージョンが多すぎて、アップストリームクラスタのパフォーマンスに影響を与えるのを防ぐことです。

ノート：

たとえば、一部のシナリオでは、 Dumpling/ BRを使用した完全レプリケーションの後に増分レプリケーションにTiCDCを使用する場合、デフォルトの24時間のgc-ttlでは不十分な場合があります。 TiCDCサーバーを起動するときは、 gc-ttlに適切な値を指定する必要があります。

TiCDCガベージコレクション（GC）セーフポイントの完全な動作は何ですか？

TiCDCサービスの開始後にレプリケーションタスクが開始された場合、TiCDC所有者は、すべてのレプリケーションタスクの中で最小値のcheckpoint-tsでPDサービスGCセーフポイントを更新します。サービスGCセーフポイントは、TiCDCがその時点およびそれ以降に生成されたデータを削除しないことを保証します。レプリケーションタスクが中断された場合、または手動で停止された場合、このタスクのcheckpoint-tsは変更されません。一方、PDの対応するサービスGCセーフポイントも更新されません。

レプリケーションタスクがgc-ttlで指定された時間より長く中断された場合、レプリケーションタスクはfailedステータスになり、再開できません。 PDに対応するサービスGCセーフポイントは継続されます。

TiCDCがサービスGCセーフポイントに設定する存続時間（TTL）は24時間です。つまり、TiCDCサービスが中断されてから24時間以内に回復できる場合、GCメカニズムはデータを削除しません。

TiCDCタイムゾーンとアップストリーム/ダウンストリームデータベースのタイムゾーンの関係を理解するにはどうすればよいですか？

ノート：

TiCDCサーバーのタイムゾーンを設定するときは注意してください。このタイムゾーンはタイムタイプの変換に使用されるためです。アップストリームタイムゾーン、TiCDCタイムゾーン、およびダウンストリームタイムゾーンの一貫性を保ちます。 TiCDCサーバーは、次の優先順位でタイムゾーンを選択します。

• TiCDCは、最初に--tzを使用して指定されたタイムゾーンを使用します。
• --tzが使用できない場合、TiCDCはTZ環境変数を使用して設定されたタイムゾーンを読み取ろうとします。
• TZの環境変数が使用できない場合、TiCDCはマシンのデフォルトのタイムゾーンを使用します。

--configで構成ファイルを指定せずにレプリケーションタスクを作成した場合のTiCDCのデフォルトの動作は何ですか？

-configパラメータを指定せずにcdc cli changefeed createコマンドを使用すると、TiCDCは次のデフォルトの動作でレプリケーションタスクを作成します。

• システムテーブルを除くすべてのテーブルを複製します
• 古い値機能を有効にします
• 有効なインデックスを含まないテーブルの複製をスキップします

TiCDCは、運河形式でのデータ変更の出力をサポートしていますか？

はい。 Canal出力を有効にするには、 --sink-uriパラメーターでプロトコルをcanalとして指定します。例えば：

cdc cli changefeed create --pd=http://10.0.10.25:2379 --sink-uri="kafka://127.0.0.1:9092/cdc-test?kafka-version=2.4.0&protocol=canal" --config changefeed.toml

ノート：

• この機能はTiCDC4.0.2で導入されました。
• TiCDCは現在、KafkaやPulsarなどのMQシンクにのみCanal形式でデータ変更を出力することをサポートしています。

詳細については、 レプリケーションタスクを作成するを参照してください。

TiCDCからKafkaまでのレイテンシーがますます高くなるのはなぜですか？

• TiCDCレプリケーションタスクの状態を表示するにはどうすればよいですかを確認してください。

• Kafkaの次のパラメータを調整します。

  • message.max.bytesの値をserver.propertiesから1073741824 （1 GB）に増やします。
  • replica.fetch.max.bytesの値をserver.propertiesから1073741824 （1 GB）に増やします。
  • consumer.propertiesのfetch.message.max.bytesの値を増やして、 message.max.bytesの値より大きくします。

TiCDCがデータをKafkaに複製するとき、トランザクションのすべての変更を1つのメッセージに書き込みますか？そうでない場合、それはどのような基準で変更を分割しますか？

いいえ。構成されたさまざまな配布戦略に従って、 row idは、 default 、およびtableを含むさまざまなベースで変更を分割しts 。

詳細については、 レプリケーションタスク構成ファイルを参照してください。

TiCDCがデータをKafkaに複製するとき、TiDB内の単一メッセージの最大サイズを制御できますか？

はい。 max-message-bytesパラメーターを設定して、毎回Kafkaブローカーに送信されるデータの最大サイズを制御できます（オプション、デフォルトでは10MB ）。 max-batch-sizeを設定して、各Kafkaメッセージの変更レコードの最大数を指定することもできます。現在、この設定は、Kafkaのprotocolがopen-protocol （オプション、デフォルトでは16 ）の場合にのみ有効になります。

TiCDCがデータをKafkaに複製するとき、メッセージには複数のタイプのデータ変更が含まれていますか？

はい。 1つのメッセージに複数のupdateまたはdeleteが含まれる場合があり、 updateとdeleteが共存する場合があります。

TiCDCがデータをKafkaに複製する場合、TiCDC Open Protocolの出力でタイムスタンプ、テーブル名、およびスキーマ名を表示するにはどうすればよいですか？

この情報は、Kafkaメッセージのキーに含まれています。例えば：

{
    "ts":<TS>,
    "scm":<Schema Name>,
    "tbl":<Table Name>,
    "t":1
}

詳細については、 TiCDCオープンプロトコルイベント形式を参照してください。

TiCDCがデータをKafkaに複製するとき、メッセージ内のデータ変更のタイムスタンプをどのように知ることができますか？

Kafkaメッセージのキーのtsを右に18ビット移動すると、UNIXタイムスタンプを取得できます。

TiCDCオープンプロトコルはどのようにnullを表しますか？

TiCDC Open Protocolでは、タイプコード6はnullを表します。

詳細については、 TiCDCOpenProtocol列タイプコードを参照してください。

TiCDC Open Protocolの行変更イベントがINSERTイベントなのかUPDATEイベントなのかはどうすればわかりますか？

Old Value機能が有効になっていない場合、TiCDCOpenProtocolの行変更イベントがINSERTイベントであるかUPDATEイベントであるかを判断できません。この機能が有効になっている場合は、含まれているフィールドによってイベントタイプを判別できます。

• UPDATEイベントには"p"フィールドと"u"フィールドの両方が含まれます
• INSERTイベントには"u"フィールドのみが含まれます
• DELETEイベントには"d"フィールドのみが含まれます

詳細については、 オープンプロトコル行変更イベント形式を参照してください。

TiCDCはどのくらいのPDストレージを使用しますか？

TiCDCはPDでetcdを使用して、メタデータを保存し、定期的に更新します。 etcdのMVCCとPDのデフォルトの圧縮の間の時間間隔は1時間であるため、TiCDCが使用するPDストレージの量は、この1時間以内に生成されるメタデータバージョンの量に比例します。ただし、v4.0.5、v4.0.6、およびv4.0.7では、TiCDCに頻繁な書き込みの問題があるため、1時間に1000個のテーブルが作成またはスケジュールされている場合、etcdストレージをすべて使用し、 etcdserver: mvcc: database space exceededのエラーを返します。 。このエラーが発生した後、etcdストレージをクリーンアップする必要があります。詳細については、 etcdはスペースクォータを維持しますを参照してください。クラスタをv4.0.9以降のバージョンにアップグレードすることをお勧めします。

TiCDCは大規模なトランザクションの複製をサポートしていますか？リスクはありますか？

TiCDCは、大規模なトランザクション（5 GBを超えるサイズ）を部分的にサポートします。さまざまなシナリオに応じて、次のリスクが存在する可能性があります。

• TiCDCの内部処理能力が不十分な場合、レプリケーションタスクエラーErrBufferReachLimitが発生する可能性があります。
• TiCDCの内部処理能力が不十分な場合、またはTiCDCのダウンストリームのスループット能力が不十分な場合、メモリ不足（OOM）が発生する可能性があります。

上記のエラーが発生した場合は、BRを使用して大規模なトランザクションの増分データを復元することをお勧めします。詳細な操作は次のとおりです。

1. 大規模なトランザクションのために終了したチェンジフィードのcheckpoint-tsを記録し、このTSOをBR増分バックアップの--lastbackuptsとして使用して、 増分データバックアップを実行します。
2. インクリメンタルデータをバックアップした後、BRログ出力で["Full backup Failed summary : total backup ranges: 0, total success: 0, total failed: 0"] [BackupTS=421758868510212097]に類似したログレコードを見つけることができます。このログにBackupTSを記録します。
3. インクリメンタルデータを復元する 。
4. 新しいチェンジフィードを作成し、 BackupTSからレプリケーションタスクを開始します。
5. 古いチェンジフィードを削除します。

DDLステートメントをダウンストリームのMySQL 5.7に複製する場合、時間タイプフィールドのデフォルト値に一貫性がありません。私に何ができる？

create table test (id int primary key, ts timestamp)ステートメントがアップストリームTiDBで実行されると仮定します。 TiCDCがこのステートメントをダウンストリームのMySQL5.7に複製する場合、 MySQL 5.7はデフォルト構成を使用します。レプリケーション後のテーブルスキーマは次のとおりです。 timestampフィールドのデフォルト値はCURRENT_TIMESTAMPになります：

mysql root@127.0.0.1:test> show create table test;
+-------+----------------------------------------------------------------------------------+
| Table | Create Table                                                                     |
+-------+----------------------------------------------------------------------------------+
| test  | CREATE TABLE `test` (                                                            |
|       |   `id` int(11) NOT NULL,                                                         |
|       |   `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, |
|       |   PRIMARY KEY (`id`)                                                             |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=latin1                                           |
+-------+----------------------------------------------------------------------------------+
1 row in set

結果から、レプリケーションの前後のテーブルスキーマに一貫性がないことがわかります。これは、TiDBのデフォルト値explicit_defaults_for_timestampがMySQLのデフォルト値と異なるためです。詳細については、 MySQLの互換性を参照してください。

v5.0.1またはv4.0.13以降、MySQLへのレプリケーションごとに、TiCDCは自動的にexplicit_defaults_for_timestamp = ONを設定して、時間タイプがアップストリームとダウンストリームの間で一貫していることを確認します。 v5.0.1またはv4.0.13より前のバージョンの場合、TiCDCを使用して時間タイプデータを複製するときに、一貫性のないexplicit_defaults_for_timestamp値によって引き起こされる互換性の問題に注意してください。

TiCDCレプリケーションタスクを作成すると、 enable-old-valueがtrueに設定されますが、アップストリームからのINSERT / UPDATEステートメントは、ダウンストリームにレプリケートされた後、 REPLACE INTOになります。

TiCDCでチェンジフィードが作成されると、 safe-modeの設定はデフォルトでtrueになり、アップストリームのINSERTステートメントに対して実行するREPLACE INTOステートメントが生成されUPDATE 。

現在、ユーザーはsafe-modeの設定を変更できないため、この問題は現在解決策がありません。

ダウンストリームのレプリケーションのシンクがTiDBまたはMySQLの場合、ダウンストリームデータベースのユーザーにはどのような権限が必要ですか？

シンクがTiDBまたはMySQLの場合、ダウンストリームデータベースのユーザーには次の権限が必要です。

• Select
• Index
• Insert
• Update
• Delete
• Create
• Drop
• Alter
• Create View

recover tableをダウンストリームTiDBに複製する必要がある場合は、 Superの権限が必要です。

TiCDCがディスクを使用するのはなぜですか？ TiCDCはいつディスクに書き込みますか？ TiCDCはレプリケーションパフォーマンスを向上させるためにメモリバッファを使用しますか？

アップストリームの書き込みトラフィックがピーク時にある場合、ダウンストリームはすべてのデータをタイムリーに消費できず、データが山積みになる可能性があります。 TiCDCは、ディスクを使用して、積み上げられたデータを処理します。 TiCDCは、通常の操作中にディスクにデータを書き込む必要があります。ただし、ディスクへの書き込みでは100ミリ秒以内の遅延しか発生しないため、これは通常、レプリケーションスループットとレプリケーション遅延のボトルネックにはなりません。 TiCDCはまた、メモリを使用してディスクからのデータの読み取りを高速化し、レプリケーションのパフォーマンスを向上させます。

TiCDCを使用したレプリケーションが停止したり、 TiDB LightningとBRを使用したデータの復元後に停止したりするのはなぜですか？

現在、TiCDCはTiDB LightningおよびBRと完全には互換性がありません。したがって、TiCDCによって複製されるテーブルでTiDB LightningおよびBRを使用することは避けてください。