TiDBBinlogのエラー処理

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

Kafka サーバー: メッセージが大きすぎました。Drainerがデータを Kafka にレプリケートするときにkafka server: Message was too large, server rejected it to avoid allocation error

原因: 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 Binlogがすべての TiDB インスタンスで有効になっていて、正常に実行されていることを確認する必要があります。クラスターのバージョンが 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設定項目を参照してください。