TiDB Binlog FAQ

このドキュメントは、TiDB Binlogに関するよくある質問（FAQ）を集めたものです。

TiDB Binlogを有効にすると、TiDBのパフォーマンスにどのような影響がありますか？

• クエリへの影響はありません。

• INSERT 、およびDELETEのトランザクションにはわずかなパフォーマンスの影響がありUPDATE 。レイテンシーでは、トランザクションがコミットされる前に、TiKVプリライトステージでp-binlogが同時に書き込まれます。一般に、binlogの書き込みはTiKVの事前書き込みよりも高速であるため、レイテンシーは増加しません。ポンプの監視パネルでbinlogの書き込みの応答時間を確認できます。

TiDB Binlogのレプリケーションレイテンシはどのくらいですか？

TiDB Binlogレプリケーションの遅延は秒単位で測定されます。これは、通常、オフピーク時に約3秒です。

DrainerがダウンストリームのMySQLまたはTiDBクラスタにデータを複製するために必要な特権は何ですか？

ダウンストリームのMySQLまたはTiDBクラスタにデータを複製するには、Drainerに次の権限が必要です。

• 入れる
• アップデート
• 消去
• 作成
• 落とす
• 変更
• 実行する
• 索引
• 選択する

ポンプディスクがほぼいっぱいになった場合はどうすればよいですか？

1. PumpのGCが正常に機能するかどうかを確認します。

   • Pumpの監視パネルのgc_tso時間が設定ファイルの時間と同じであるかどうかを確認します。

2. GCが正常に機能する場合は、次の手順を実行して、単一のポンプに必要なスペースの量を減らします。

   • PumpのGCパラメータを変更して、データを保持する日数を減らします。

   • ポンプインスタンスを追加します。

ドレイナーの複製が中断された場合はどうすればよいですか？

次のコマンドを実行して、Pumpのステータスが正常であるかどうか、およびoffline状態にないすべてのPumpインスタンスが実行されているかどうかを確認します。

binlogctl -cmd pumps

次に、Drainerモニターまたはログが対応するエラーを出力するかどうかを確認します。もしそうなら、それに応じてそれらを解決します。

DrainerがダウンストリームのMySQLまたはTiDBクラスタにデータを複製するのが遅い場合はどうすればよいですか？

次の監視項目を確認してください。

• Drainerイベントの監視メトリックについては、DrainerがDELETE秒あたりINSERT 、およびUPDATEのトランザクションをダウンストリームに複製する速度を確認してください。

• SQLクエリ時間の監視メトリックについては、DrainerがダウンストリームでSQLステートメントを実行するのにかかる時間を確認してください。

レプリケーションが遅い場合の考えられる原因と解決策：

• レプリケートされたデータベースに主キーまたは一意のインデックスのないテーブルが含まれている場合は、テーブルに主キーを追加します。

• Drainerとダウンストリームの間のレイテンシーが高い場合は、Drainerのworker-countパラメーターの値を増やします。データセンター間のレプリケーションでは、Drainerをダウンストリームにデプロイすることをお勧めします。

• 下流の負荷が高くない場合は、Drainerのworker-countパラメータの値を大きくしてください。

Pumpインスタンスがクラッシュした場合はどうすればよいですか？

Pumpインスタンスがクラッシュした場合、Drainerはこのインスタンスのデータを取得できないため、データをダウンストリームに複製できません。このPumpインスタンスが通常の状態に回復できる場合、Drainerはレプリケーションを再開します。そうでない場合は、次の手順を実行します。

1. binlogctlを使用して、このPumpインスタンスの状態をofflineに変更しますを使用して、このPumpインスタンスのデータを破棄します。

2. Drainerはこのポンプインスタンスのデータを取得できないため、ダウンストリームとアップストリームのデータに一貫性がありません。この状況では、完全バックアップと増分バックアップを再度実行してください。手順は次のとおりです。

   1. ドレイナーを停止します。

   2. アップストリームで完全バックアップを実行します。

   3. tidb_binlog.checkpointのテーブルを含むダウンストリームのデータをクリアします。

   4. フルバックアップをダウンストリームに復元します。

   5. Drainerをデプロイし、最初のレプリケーションの開始点としてinitialCommitTs （完全バックアップのスナップショットタイムスタンプとしてinitialCommitTsを設定）を使用します。

チェックポイントとは何ですか？

チェックポイントは、Drainerがダウンストリームに複製するcommit-tsを記録します。 Drainerが再起動すると、チェックポイントを読み取り、対応するcommit-tsから開始してデータをダウンストリームに複製します。 ["write save point"] [ts=411222863322546177] Drainerログは、対応するタイムスタンプとともにチェックポイントを保存することを意味します。

チェックポイントは、さまざまなタイプのダウンストリームプラットフォームに対してさまざまな方法で保存されます。

• MySQL / TiDBの場合、 tidb_binlog.checkpointのテーブルに保存されます。

• Kafka / fileの場合、対応する構成ディレクトリのファイルに保存されます。

kafka / fileのデータにはcommit-tsが含まれているため、チェックポイントが失われた場合、ダウンストリームで最新のデータを使用することにより、ダウンストリームデータの最新のcommit-tsをチェックできます。

ドレイナーは、開始時にチェックポイントを読み取ります。 Drainerがチェックポイントを読み取れない場合は、構成されたinitialCommitTsを初期レプリケーションの開始点として使用します。

Drainerに障害が発生し、ダウンストリームのデータが残っている場合に、Drainerを新しいマシンに再デプロイするにはどうすればよいですか？

ダウンストリームのデータが影響を受けない場合は、対応するチェックポイントからデータを複製できる限り、新しいマシンにDrainerを再デプロイできます。

• チェックポイントが失われていない場合は、次の手順を実行します。

  1. 新しいDrainerをデプロイして開始します（Drainerはチェックポイントを読み取り、レプリケーションを再開できます）。

  2. binlogctlを使用して、古いDrainerの状態をofflineに変更しますを使用します。

• チェックポイントが失われた場合は、次の手順を実行します。

  1. 新しいドレイナーを配置するには、古いドレイナーのcommit-tsつを新しいドレイナーのinitialCommitTsとして取得します。

  2. binlogctlを使用して、古いDrainerの状態をofflineに変更しますを使用します。

フルバックアップとbinlogバックアップファイルを使用してクラスタのデータを復元するにはどうすればよいですか？

1. クラスタをクリーンアップし、完全バックアップを復元します。

2. バックアップファイルの最新データを復元するには、Reparoを使用してstart-tso ={完全バックアップのスナップショットタイムスタンプ+1}およびend-ts =0に設定します（または、特定の時点を指定できます）。

プライマリ-セカンダリレプリケーションでignore-errorを有効にすると、重大なエラーが発生する場合にDrainerを再デプロイするにはどうすればよいですか？

ignore-errorを有効にした後でTiDBがbinlogの書き込みに失敗したときに重大なエラーがトリガーされた場合、TiDBはbinlogの書き込みを停止し、binlogデータの損失が発生します。レプリケーションを再開するには、次の手順を実行します。

1. Drainerインスタンスを停止します。

2. クリティカルエラーをトリガーしたtidb-serverつのインスタンスを再起動し、binlogの書き込みを再開します（クリティカルエラーがトリガーされた後、TiDBはPumpにbinlogを書き込みません）。

3. アップストリームで完全バックアップを実行します。

4. tidb_binlog.checkpointのテーブルを含むダウンストリームのデータをクリアします。

5. フルバックアップをダウンストリームに復元します。

6. Drainerをデプロイし、最初のレプリケーションの開始点としてinitialCommitTs （完全バックアップのスナップショットタイムスタンプとしてinitialCommitTsを設定）を使用します。

ポンプまたはドレイナーノードを一時停止または閉じることができるのはいつですか？

ポンプまたはドレイナーの状態の説明と、プロセスを開始および終了する方法については、 TiDBBinlogクラスターの操作を参照してください。

サービスを一時的に停止する必要がある場合は、ポンプノードまたはドレイナーノードを一時停止します。例えば：

• バージョンアップグレード

  プロセスが停止した後、新しいバイナリを使用してサービスを再起動します。

• サーバのメンテナンス

  サーバーがダウンタイムのメンテナンスを必要とする場合は、プロセスを終了し、メンテナンスの終了後にサービスを再開します。

サービスが不要になったら、ポンプノードまたはドレイナーノードを閉じます。例えば：

• ポンプスケールイン

  あまり多くのポンプサービスを必要としない場合は、それらのいくつかを閉じます。

• レプリケーションタスクのキャンセル

  データをダウンストリームデータベースに複製する必要がなくなった場合は、対応するDrainerノードを閉じます。

• サービスの移行

  サービスを別のサーバーに移行する必要がある場合は、サービスを閉じて、新しいサーバーに再デプロイします。

ポンプまたはドレイナープロセスを一時停止するにはどうすればよいですか？

• プロセスを直接強制終了します。

  ノート：

  kill -9コマンドは使用しないでください。そうしないと、PumpまたはDrainerノードは信号を処理できません。

• PumpまたはDrainerノードがフォアグラウンドで実行されている場合は、 Ctrl + Cを押して一時停止します。

• binlogctlでpause-pumpまたはpause-drainerコマンドを使用します。

binlogctlでupdate-pumpまたはupdate-drainer drainerコマンドを使用して、PumpまたはDrainerサービスを一時停止できますか？

いいえupdate-pumpまたはupdate-drainerコマンドは、対応する操作を実行するようにポンプまたはドレイナーに通知することなく、PDに保存されている状態情報を直接変更します。 2つのコマンドを誤用すると、データレプリケーションが中断され、データが失われる可能性があります。

binlogctlでupdate-pumpまたはupdate-drainer drainerコマンドを使用して、PumpまたはDrainerサービスを閉じることはできますか？

いいえupdate-pumpまたはupdate-drainerコマンドは、対応する操作を実行するようにポンプまたはドレイナーに通知することなく、PDに保存されている状態情報を直接変更します。 2つのコマンドを誤用すると、データレプリケーションが中断され、データの不整合が発生する可能性があります。例えば：

• Pumpノードが正常に実行されているかpaused状態にある場合、 update-pumpコマンドを使用してPump状態をofflineに設定すると、Drainerノードは7Pumpからのofflineデータのプルを停止します。この状況では、最新のbinlogをDrainerノードに複製できないため、アップストリームとダウンストリームの間でデータの不整合が発生します。
• Drainerノードが正常に実行されているときに、 update-drainerコマンドを使用してDrainer状態をofflineに設定すると、新しく開始されたPumpノードはonline状態のDrainerノードにのみ通知します。この状況では、 offline DrainerはPumpノードからbinlogデータを時間内にプルできず、アップストリームとダウンストリームの間でデータの不整合が発生します。

binlogctlのupdate-pumpコマンドを使用して、ポンプの状態をpausedに設定できるのはいつですか。

いくつかの異常な状況では、ポンプはその状態を正しく維持できません。次に、 update-pumpコマンドを使用して状態を変更します。

たとえば、Pumpプロセスが異常終了した場合（パニックが発生したときにプロセスを直接終了した場合、または誤ってkill -9コマンドを使用してプロセスを強制終了した場合）、PDに保存されたPump状態情報はonlineのままです。この状況で、現時点でサービスを回復するためにPumpを再起動する必要がない場合は、 update-pumpコマンドを使用してPumpの状態をpausedに更新します。そうすれば、TiDBがbinlogを書き込み、Drainerがbinlogをプルするときに中断を回避できます。

binlogctlのupdate-drainer drainerコマンドを使用して、Drainerの状態をpausedに設定できるのはいつですか。

一部の異常な状況では、Drainerノードがその状態を正しく維持できず、レプリケーションタスクに影響を及ぼしています。次に、 update-drainerコマンドを使用して状態を変更します。

たとえば、Drainerプロセスが異常終了した場合（パニックが発生したときにプロセスを直接終了した場合、または誤ってkill -9コマンドを使用してプロセスを強制終了した場合）、PDに保存されたDrainer状態情報はonlineのままです。ポンプノードが開始されると、終了したドレイナーノードへの通知に失敗し（ notify drainer ...エラー）、ポンプノードに障害が発生します。この状況では、 update-drainerコマンドを使用してDrainerの状態をpausedに更新し、Pumpノードを再起動します。

ポンプまたはドレイナーノードを閉じるにはどうすればよいですか？

現在、binlogctlのoffline-pumpまたはoffline-drainerコマンドのみを使用して、PumpまたはDrainerノードを閉じることができます。

binlogctlでupdate-pumpコマンドを使用して、ポンプの状態をofflineに設定できるのはいつですか。

次の状況では、 update-pumpコマンドを使用してポンプ状態をofflineに設定できます。

• Pumpプロセスが異常終了し、サービスを回復できない場合、レプリケーションタスクは中断されます。レプリケーションを回復し、binlogデータの損失を受け入れる場合は、 update-pumpコマンドを使用してPump状態をofflineに設定します。次に、DrainerノードはPumpノードからのbinlogのプルを停止し、データの複製を続行します。
• いくつかの古いポンプノードは、履歴タスクから残されています。それらのプロセスは終了し、それらのサービスはもはや必要ありません。次に、 update-pumpコマンドを使用して状態をofflineに設定します。

その他の状況では、 offline-pumpコマンドを使用して、通常のプロセスであるポンプサービスを閉じます。

終了してpausedに設定されているPumpノードを閉じたい場合、binlogctlのupdate-pumpコマンドを使用してPump状態をofflineに設定できますか？

Pumpプロセスが終了し、ノードがpaused状態の場合、ノード内のすべてのbinlogデータがそのダウンストリームのDrainerノードで消費されるわけではありません。したがって、そうすると、アップストリームとダウンストリームの間でデータの不整合が発生する可能性があります。この状況では、Pumpを再起動し、 offline-pumpコマンドを使用してPumpノードを閉じます。

binlogctlのupdate-drainer drainerコマンドを使用して、Drainerの状態をofflineに設定できるのはいつですか。

一部の古いDrainerノードは、履歴タスクから残されています。それらのプロセスは終了し、それらのサービスはもはや必要ありません。次に、 update-drainerコマンドを使用して状態をofflineに設定します。

change pumpのchange drainerやドレイナーの変更などのSQL操作を使用して、ポンプまたはドレイナーサービスを一時停止または閉じることはできますか？

いいえ。これらのSQL操作の詳細については、 SQLステートメントを使用してPumpまたはDrainerを管理するを参照してください。

これらのSQL操作は、PDに保存されている状態情報を直接変更し、binlogctlのupdate-pumpおよびupdate-drainerコマンドと機能的に同等です。 PumpまたはDrainerサービスを一時停止または閉じるには、binlogctlツールを使用します。

アップストリームデータベースでサポートされている一部のDDLステートメントがダウンストリームデータベースで実行されたときにエラーを引き起こす場合はどうすればよいですか？

問題を解決するには、次の手順に従います。

1. drainer.logを確認してください。 Drainerプロセスが終了する前に、最後に失敗したDDL操作をexec failedで検索します。

2. DDLバージョンをダウンストリームと互換性のあるバージョンに変更します。ダウンストリームデータベースでこの手順を手動で実行します。

3. drainer.logを確認してください。失敗したDDL操作を検索し、この操作のcommit-tsを見つけます。例えば：

   [2020/05/21 09:51:58.019 +08:00] [INFO] [syncer.go:398] ["add ddl item to syncer, you can add this commit ts to `ignore-txn-commit-ts` to skip this ddl if needed"] [sql="ALTER TABLE `test` ADD INDEX (`index1`)"] ["commit ts"=416815754209656834].
   

4. drainer.tomlの構成ファイルを変更します。 ignore-txn-commit-ts項目にcommit-tsを追加し、Drainerノードを再起動します。

TiDBがbinlogへの書き込みに失敗してスタックし、 listener stopped, waiting for manual stopていることがログに表示されます

TiDB v3.0.12以前のバージョンでは、binlogの書き込みに失敗すると、TiDBが致命的なエラーを報告します。 TiDBは自動的に終了せず、サービスを停止するだけで、スタックしているように見えます。ログにlistener stopped, waiting for manual stopのエラーが表示されます。

binlog書き込み失敗の具体的な原因を特定する必要があります。 binlogがダウンストリームにゆっくりと書き込まれるために障害が発生した場合は、Pumpをスケールアウトするか、binlogを書き込むためのタイムアウト時間を増やすことを検討できます。

v3.0.13以降、エラー報告ロジックが最適化されています。 binlogの書き込みに失敗すると、トランザクションの実行が失敗し、TiDB Binlogはエラーを返しますが、TiDBがスタックすることはありません。

TiDBは重複したbinlogをPumpに書き込みます

この問題は、ダウンストリームおよびレプリケーションロジックには影響しません。

binlogの書き込みが失敗するかタイムアウトになると、TiDBは、書き込みが成功するまで、次に使用可能なPumpノードへのbinlogの書き込みを再試行します。したがって、Pumpノードへのbinlogの書き込みが遅く、TiDBタイムアウト（デフォルトは15秒）が発生した場合、TiDBは書き込みが失敗したと判断し、次のPumpノードへの書き込みを試みます。 binlogがタイムアウトの原因となるPumpノードに実際に正常に書き込まれる場合、同じbinlogが複数のPumpノードに書き込まれます。 Drainerがbinlogを処理するとき、同じTSOでbinlogを自動的に重複排除するため、この重複書き込みはダウンストリームおよびレプリケーションロジックに影響を与えません。

Reparoは、完全および増分復元プロセス中に中断されます。ログの最後のTSOを使用してレプリケーションを再開できますか？

はい。 Reparoは、起動時にセーフモードを自動的に有効にしません。次の手順を手動で実行する必要があります。

1. Reparoが中断された後、最後のTSOをcheckpoint-tsoとしてログに記録します。
2. Reparo構成ファイルを変更し、構成項目start-tsoをcheckpoint-tso + 1に設定し、 stop-tsoをcheckpoint-tso + 80,000,000,000に設定し（ checkpoint-tsoの約5分後）、 safe-modeをtrueに設定します。 Reparoを起動すると、Reparoはデータをstop-tsoに複製してから、自動的に停止します。
3. Reparoが自動的に停止した後、 start-tsoからcheckpoint tso + 80,000,000,001に設定し、 stop-tsoから0に設定し、 safe-modeからfalseに設定します。 Reparoを起動して、レプリケーションを再開します。