TiDB Self-Managed
Learning Center
お問い合わせ

Binlogバイナリログに関するよくある質問

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

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

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

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

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

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

Drainer が下流の MySQL またはDrainerクラスターにデータをレプリケートするために必要な権限は何ですか?

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

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

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

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

    • ポンプの監視パネルのgc_tso時刻が設定ファイルの時刻と一致しているか確認してください。

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

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

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

Drainerの複製が中断された場合、どうすればよいですか?

以下のコマンドを実行して、 Pumpの状態が正常かどうか、およびoffline状態以外のすべてのPumpインスタンスが稼働しているかどうかを確認します。

binlogctl -cmd pumps

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

Drainer が下流の MySQL またはDrainerクラスターにデータをレプリケートするのが遅い場合はどうすればよいですか?

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

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

  • SQL Query Timeモニタリング メトリックについては、 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を設定) を使用します。

チェックポイントとは？

Checkpoint は、 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を再デプロイできます。

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

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

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

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

    1. 新しいDrainerをデプロイするには、古いDrainerのcommit-tsを新しいDrainerのinitialCommitTsとして取得します。

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

フル バックアップと binlog バックアップ ファイルを使用してクラスターのデータを復元する方法を教えてください。

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

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

Primary-Secondary レプリケーションで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状態の説明と、プロセスの開始方法と終了方法については、 TiDB 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ノードはoffline Pumpからのバイナリログ データのプルを停止します。この状況では、最新の 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 がバイナリログを書き込み、 Drainerがバイナリログをプルする際の中断を回避できます。

binlogctl でupdate-drainer 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プロセスが異常終了し、サービスを回復できない場合、レプリケーション タスクは中断されます。レプリケーションを回復し、バイナリログ データの一部の損失を受け入れる場合は、 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 コマンドを使用してDrainerの状態をofflineに設定できるのはいつですか?

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

change pumpのchange drainerやドレインの変更などの SQL 操作を使用して、PumpまたはDrainerサービスを一時停止または終了できますか?

いいえ。これらの 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構成ファイルを変更します。 commit-ts in the ignore-txn-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 がダウンストリームにゆっくりと書き込まれるために障害が発生した場合は、 Pumpをスケールアウトするか、binlog を書き込むためのタイムアウト時間を長くすることを検討できます。

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

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

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

バイナリログの書き込みが失敗するかタイムアウトになると、TiDB は、書き込みが成功するまで、次に使用可能なPumpノードにバイナリログの書き込みを再試行します。したがって、 Pumpノードへのバイナリログの書き込みが遅く、TiDB タイムアウト (デフォルトは 15 秒) が発生する場合、TiDB は書き込みが失敗したと判断し、次のPumpノードへの書き込みを試みます。 binlog が実際にタイムアウトの原因となったPumpノードに正常に書き込まれた場合、同じ binlog が複数のPumpノードに書き込まれます。 Drainerがバイナリログを処理するとき、同じ 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 ～ 0 safe-mode falseを設定しstop-tso 。 Reparoを起動してレプリケーションを再開します。