max_binlog_cache_sizeパラメーターのMGR変更により、例外が発生します

著者：Gao Peng（スクリーン名8奇妙）、「MySQLマスターの原理の深い理解32から」シリーズの著者。
シリーズリンク：https：//www.jianshu.com/nb/43148932

1.問題の原因

前の友人がmax_binlog_cache_sizeを8mに設定し、後でこのパラメーターをオンラインで変更したため、これは友人の問題ですが、その結果、プライマリノードと他の2つの2番目のノードを除く3ノードのMGRクラスター全体がオフラインになりました。おおよそのログは次のとおりです。

2つ目は、binlogキャッシュを使用するおおよそのプロセスです。

これも私が以前に書いたプロセスです。

読み取りおよび書き込みトランザクションを開きます。
「DML」ステートメントを実行し、「DML」ステートメントが初めて実行されるときに、メモリスペースをbinlogキャッシュバッファに割り当てます。
'DML'ステートメントの実行中に生成されたイベントは、binlogキャッシュバッファーに継続的に書き込まれます。
binlogキャッシュバッファがいっぱいになると、binlogキャッシュバッファ内のデータがbinlogキャッシュ一時ファイルに書き込まれ、binlogキャッシュバッファがクリアされます。一時ファイル名はMLで始まります。
トランザクションがコミットされ、binlogキャッシュバッファーとbinlogキャッシュ一時ファイルデータがすべてバイナリログに書き込まれて修復され、binlogキャッシュバッファーとbinlogキャッシュ一時ファイルが解放されます。ただし、binlogキャッシュバッファのメモリスペースは次のトランザクション用に予約されていますが、binlogキャッシュ一時ファイルは0に切り捨てられ、ファイル記述子は予約されていることに注意してください。実際、IO_CACHE構造は予約されており、IO_CACHEで割り当てられたメモリスペースと一時ファイルファイル記述子は予約されています。
切断すると、このプロセスはIO_CACHEを解放し、IO_CACHEが保持しているbinlogキャッシュバッファメモリと、IO_CACHEが保持しているbinlogキャッシュ一時ファイルを解放します。

3つ目は、max_binlog_cache_sizeパラメーターの役割です。

この部分も以前に記録されています。

max_binlog_cache_size：変更は、binlogキャッシュ一時ファイルの最大容量を定義するsetglobalを使用して変更する必要があります。トランザクションのイベントの合計量が（max_binlog_cache_size + binlog_cache_size）のサイズより大きい場合、エラーは次のように報告されます。

ERROR 1197 (HY000): Multi-statement transaction required more than
'max_binlog_cache_size' bytes of storage; increase this mysqld variable
and try again

関数_my_b_writeに次のコードが表示されます。

if (pos_in_file+info->buffer_length > info->end_of_file) //判断binlog cache临时文件的位置加上本次需要写盘的数据大于info->end_of_file的大小则抛错
  {
    errno=EFBIG;
    set_my_errno(EFBIG);
    return info->error = -1;
  }

info-> end_of_fileのサイズは、パラメーターmax_binlog_cache_sizeから取得されます。

4、問題を分析する

2番目のノードのエラーレポートから、アプライヤースレッドによって適用されたトランザクションは、max_binlog_cache_sizeによって設定されたサイズを超えていますが、サイズは友人によって変更されており、メインライブラリはこのエラーを報告しませんでした。
MGRが開始された瞬間から、MGRアプライヤースレッドが停止せず、同様のマスタースレーブsqlスレッドが同じであることがわかっています。設定されたグローバルパラメーターを使用してパラメーターを変更しますが、実際には、MGRアプライヤースレッドは停止しません。有効になります。
ただし、メインライブラリの場合、パラメータを変更した後、アプリケーションを再起動して再接続する限り、パラメータが有効になります。この時点で、実際には、プライマリセッションのmax_binlog_cache_sizeと2番目のアプライヤーのmax_binlog_cache_sizeに一貫性がありません。メインライブラリがより大きなトランザクションを実行すると、このトランザクションのbinlogは、以前に設定された値よりも大きくなります。メインライブラリは成功しますが、アプライヤースレッドのmax_binlog_cache_sizeが小さすぎるため、スタンバイノードはクラスター全体を離れます。
これは、MySQLのsqlスレッドをデバッグすることで確認できます。