TiDBBinlogエラー処理

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

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

ポンプはno space left on device

原因：Pumpがbinlogデータを正常に書き込むには、ローカルディスク容量が不足しています。

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

ポンプの始動時に、 fail to notify all living drainer

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

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

TiDBBinlogレプリケーション中にデータ損失が発生します

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

アップストリームトランザクションが大きい場合、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構成項目をご覧ください。