TiDBBinlogエラー処理

このドキュメントでは、 TiDB Binlog を使用する際に発生する可能性のある一般的なエラーと、それらのエラーの解決策について説明します。

kafka server: Message was too large, server rejected it to avoid allocation error Drainer がデータを Kafka に複製するときに返されるエラーです。

原因: TiDB で大規模なトランザクションを実行すると、大きなサイズのbinlogデータが生成され、Kafka のメッセージ サイズの制限を超える可能性があります。

解決策: Kafka の構成パラメータを以下のように調整します。

message.max.bytes=1073741824
replica.fetch.max.bytes=1073741824
fetch.message.max.bytes=1073741824

Pumpはno space left on deviceを返します

原因: Pump がbinlogデータを正常に書き込むには、ローカル ディスク領域が不十分です。

解決策: ディスク領域をクリーンアップしてから、 Pumpを再起動します。

Pumpの起動時にfail to notify all living drainer

原因: Pumpが起動すると、状態onlineにあるすべてのDrainerノードに通知します。Drainerへの通知に失敗すると、このエラー ログが出力されます。

解決策: binlogctl ツール使用して、各Drainerノードが正常かどうかを確認します。これは、 online状態にあるすべてのDrainerノードが正常に動作していることを確認するためです。Drainer ノードの状態が実際の動作状態と一致していない場合は、binlogctl ツールを使用して状態を変更し、 Pumpを再起動します。

TiDB Binlogレプリケーション中にデータ損失が発生する

すべての TiDB インスタンスで TiDB Binlogが有効になっていて、正常に実行されていることを確認する必要があります。クラスターのバージョンが v3.0 以降の場合は、 curl {TiDB_IP}:{STATUS_PORT}/info/allコマンドを使用して、すべての TiDB インスタンスの TiDB Binlogステータスを確認します。

アップストリーム トランザクションが大きい場合、Pumpはエラーを報告しますrpc error: code = ResourceExhausted desc = trying to send message larger than max (2191430008 vs. 2147483647)

このエラーは、TiDB からPumpに送信された gRPC メッセージがサイズ制限を超えたために発生します。Pumpの起動時にmax-message-size指定することで、 Pumpが許可する gRPC メッセージの最大サイズを調整できます。

Drainerによって出力されるファイル形式の増分データに対してクリーニング メカニズムはありますか? データは削除されますか?

• Drainer v3.0.x には、ファイル形式の増分データのクリーニング メカニズムはありません。
• v4.0.xバージョンでは、時間ベースのデータクリーニングメカニズムがあります。詳細については、 ドレイナーのretention-time設定項目を参照してください。