エラー 1197 (HY000) 行 4: 「max_binlog_cache_size」を超える複数ステートメントのトランザクションが必要ですストレージのバイト数。この mysqld 変数を増やして再試行してください
これは、マルチステートメント フードがより大きな max_binlog_cache_size を要求することを意味します。このパラメータ値を増やして再試行する必要があります。
このとき、マスターが同期されておらず、SQL スレッドが終了したというアラームを受け取りました。
システムにログインしてマスターとスレーブの状態を確認したところ、同僚の SQL に関連していることがわかりました。
私は同僚に操作の SQL について尋ねました。
まずテーブルをコピーします。方法は次のとおりです。 table_A のようにテーブル table_B を作成し、次に insert into table_B select * from table_A を使用します。
合計 4 つのテーブルがありますが、正常に実行されたのは 1 つのテーブルだけであり、後から上記のエラーが報告されました。
注: 同様の方法で作成されたテーブルを使用する利点は、ソース テーブルと同じテーブル構造、インデックス、ストレージ エンジンなどを持つことができることです。
欠点は、空のテーブルが作成され、データを新しいテーブルに再度挿入する必要があることです。
しかし、なぜこの方法ではライブラリからのコピーが中断されるのでしょうか?他のスレーブ ライブラリは正常です。
その理由は、レプリケーションが中断されるスレーブ ライブラリの役割がバックアップ ライブラリであり、binlog が有効で binlog 形式が ROW であり、他のスレーブ ライブラリでは binlog が有効になっていないためです。
mysql> 'binlog_format'; のような変数を表示します。
+---------------+-------+
|変数名 |値 |
+---------------+-------+
| binlog_format |行 |
+---------------+-------+
行形式の binlog の機能: 行モードでは、実行されたすべてのステートメントがログに記録されると、各行への変更として記録されるため、大量のログ コンテンツが生成される可能性があります。したがって、バイナリ キャッシュが小さすぎるため、バイナリ キャッシュが中断されてしまいます。
エラーの原因がわかれば、問題を解決できます。
まずこのパラメータのサイズを大きくします: set global max_binlog_cache_size=XXXXXXX (これはシステムを再起動すると無効になります)
次に、複製プロセスの開始スレーブを開始します。
レプリケーション ステータスの表示 show slide status\G
マスター/スレーブ レプリケーションが通常に戻る
同僚の SQL は、上記のエラーが発生することなく再度実行されました。
sql = "'max_binlog_cache_size'; のようなグローバル変数を表示"
40G
# sql ='set global max_binlog_cache_size=40*1024*1024*1024;'