TiDBBinlogよくある質問

このドキュメントでは、 TiDB Binlogに関するよくある質問 (FAQ) をまとめています。

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

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

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

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

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

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

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

• 入れる
• アップデート
• 消去
• 作成する
• 落とす
• アルター
• 実行する
• 索引
• 選択する
• ビューの作成

Pumpディスクがほぼいっぱいになった場合はどうすればいいですか?

1. ポンプの GC が正常に動作するかどうかを確認します。

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

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

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

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

Drainerレプリケーションが中断された場合、どうすればよいですか?

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

binlogctl -cmd pumps

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

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

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

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

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

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

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

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

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

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

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

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

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

   1. Drainerを停止します。

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

   3. tidb_binlog.checkpointテーブルを含む下流のデータをクリアします。

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

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

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

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

チェックポイントは、ダウンストリーム プラットフォームの種類に応じて異なる方法で保存されます。

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

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

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

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

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

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

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

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

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

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

  1. 新しいDrainerを展開するには、古いDrainerのcommit-ts新しいDrainerの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を設定) を使用します。

PumpまたはDrainerノードを一時停止または閉じることができるのはいつですか?

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

サービスを一時的に停止する必要がある場合は、PumpまたはDrainerノードを一時停止します。例:

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

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

• サーバのメンテナンス

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

サービスが不要になったら、PumpまたはDrainerノードを閉じます。例:

• Pumpスケールイン

  あまり多くのPumpサービスが必要ない場合は、いくつかを閉じます。

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

  下流のデータベースにデータを複製する必要がなくなった場合は、対応するDrainerノードを閉じます。

• サービス移行

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

PumpまたはDrainerのプロセスを一時停止するにはどうすればよいですか?

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

  注記：

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

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

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

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

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

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

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

• Pumpノードが正常に実行されているか、またはpaused状態にあるときに、 update-pumpコマンドを使用してPump状態をofflineに設定すると、 Drainerノードはoffline Pumpからのbinlogデータの取得を停止します。この状況では、最新のbinlog をDrainerノードに複製できず、上流と下流の間でデータの不整合が発生します。
• Drainerノードが正常に動作しているときに、 update-drainerコマンドを使用してDrainer状態をofflineに設定すると、新しく起動したPumpノードはonline状態のDrainerノードにのみ通知します。この状況では、 offline Drainer はPumpノードからbinlogデータを時間内に取得できず、上流と下流の間でデータの不整合が発生します。

いつ binlogctl のupdate-pumpコマンドを使用して、Pumpの状態をpausedに設定できますか?

異常な状況によっては、Pumpが状態を正しく維持できないことがあります。その場合は、 update-pumpコマンドを使用して状態を変更します。

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

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

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

たとえば、 Drainerプロセスが異常終了した場合 (panicが発生したときにプロセスを直接終了するか、誤ってkill -9コマンドを使用してプロセスを強制終了した場合)、PD に保存されているDrainerPump情報はonlineままです。Pump ノードを起動すると、終了したDrainerノードに通知できず ( notify drainer ...エラー)、 Pumpノードが失敗します。この状況では、 update-drainerコマンドを使用してDrainer状態をpausedに更新し、 Pumpノードを再起動します。

PumpまたはDrainerノードを閉じるにはどうすればよいですか?

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

いつ binlogctl のupdate-pumpコマンドを使用して、Pumpの状態をofflineに設定できますか?

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

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

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

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

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

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

過去のタスクから古いDrainerノードがいくつか残っています。それらのプロセスは終了しており、サービスは不要になっています。次に、 update-drainerコマンドを使用して、それらの状態をofflineに設定します。

PumpまたはDrainerサービスを一時停止または閉じるには、 change pumpやchange drainerなどの SQL 操作を使用できますか?

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

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

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

この問題を解決するには、次の手順に従ってください。

1. チェックdrainer.log 。DrainerDrainerが終了する前に最後に失敗した 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ます。5 項目に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 がダウンストリームにゆっくりと書き込まれるためにbinlogが発生する場合は、 Pumpをスケールアウトするか、 binlog書き込みのタイムアウト時間を長くすることを検討できます。

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

TiDBは重複したバイナリログをPumpに書き込む

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

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

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 を起動してレプリケーションを再開します。