Binlogエラー処理

このドキュメントでは、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を再起動します。

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

TiDB BinlogがすべてのTiDBインスタンスで有効になっていて、正常に実行されていることを確認する必要があります。クラスタのバージョンがv3.0より後の場合は、 curl {TiDB_IP}:{STATUS_PORT}/info/allコマンドを使用して、すべての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構成項目をご覧ください。