重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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または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またはDrainerクラスタにデータを複製するのが遅い場合はどうすればよいですか?

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

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

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

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

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

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

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

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

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

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

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

    1. Drainerを停止します。

    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は、開始時にチェックポイントを読み取ります。 Drainerがチェックポイントを読み取れない場合、初期レプリケーションの開始点として構成済みのinitialCommitTsを使用します。

Drainerを再デプロイするにはどうすればよいですか?

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

フルバックアップと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はBinlogをPumpに書き込みません)。

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

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

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

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

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

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

サービスを一時的に停止する必要がある場合は、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 drainerコマンドを使用して、 PumpまたはDrainerサービスを一時停止できますか?

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

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

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

  • Pumpノードが正常に実行されているかpaused状態にあるときに、 update-pumpコマンドを使用してPump状態をofflineに設定すると、 DrainerノードはPumpからのofflineデータのプルを停止します。この状況では、最新の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がDrainerをプルするときに、中断を回避できます。

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

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

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

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

現在、binlogctlでoffline-pumpまたはoffline-drainerコマンドを使用して、 Pumpまたは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サービスを閉じます。

警告

binlogデータの損失とアップストリームとダウンストリーム間のデータの不整合を許容できる場合、またはPumpノードに保存されているbinlogデータが不要になった場合を除いて、 update-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 pumpchange drainerやDrainerの変更などのSQL操作を使用して、Pumpまたはドレイナーサービスを一時停止または閉じることはできますか?

いいえ。これらの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-tsocheckpoint-tso + 1に設定し、 stop-tsocheckpoint-tso + 80,000,000,000に設定し( checkpoint-tsoの約5分後)、 safe-modetrueに設定します。 Reparoを起動すると、 Reparoはデータをstop-tsoに複製してから、自動的に停止します。
  3. Reparoが自動的に停止した後、 start-tsoに設定し、 stop-tsosafe-modeし、 checkpoint tso + 80,000,000,001false0 。 Reparoを起動して、レプリケーションを再開します。
このページの内容