read_buffer_sizeはデータ複製を破壊する可能性があります

Miguel Angel Nietoの最新記事read_buffer_sizeの翻訳は、 あなたの複製を破壊する可能性があります



レプリケーションに影響を与える可能性があり、時には多くのトラブルを引き起こす変数がいくつかあります。 この投稿では、read_buffer_size変数について説明し、この変数とmax_allowed_pa​​cketがレプリケーションを破壊する方法について説明します。



マスターマスタレプリケーションのセットアップがあるとします。



max_allowed_packet = 32M

read_buffer_size = 100M








レプリケーションを中断するために、LOAD DATA INFILEを使用して400万行をロードします。



MasterA (test) > LOAD DATA INFILE '/tmp/data' INTO TABLE t;

Query OK, 4510080 rows affected (26.89 sec)








しばらくすると、MasterAでSHOW SLAVE STATUSコマンドを実行すると、次の出力が得られます。



Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master;the first event 'mysql-bin.000002' at 74416925, the last event read from './mysql-bin.000004' at 171, the last byte read from './mysql-bin.000004' at 190.'







とても奇妙です! データをMasterAにアップロードしましたが、レプリケーションが破損し、max_allowed_pa​​cketに関連するエラーが発生しました。 次のステップは、両方のマスターのバイナリログを確認することです:



MasterA:



masterA> mysqlbinlog data/mysql-bin.000004 | grep block_len

#Begin_load_query: file_id: 1 block_len: 33554432

#Append_block: file_id: 1 block_len: 33554432

#Append_block: file_id: 1 block_len: 33554432

#Append_block: file_id: 1 block_len: 4194304

#Append_block: file_id: 1 block_len: 33554432

#Append_block: file_id: 1 block_len: 10420608








max_allowed_pa​​cket(33554432)より大きいブロックはありません。



MasterB:



masterB> mysqlbinlog data/mysql-bin.000004 | grep block_len

#Begin_load_query: file_id: 1 block_len: 33555308

#Append_block: file_id: 1 block_len: 33555308

#Append_block: file_id: 1 block_len: 33555308

#Append_block: file_id: 1 block_len: 4191676

#Append_block: file_id: 1 block_len: 33555308

#Append_block: file_id: 1 block_len: 10419732








違いに気づきましたか? 33555308はmax_allowed_pa​​cket(33554432)よりも大きいため、Master2は安全な値よりも876バイト多くのブロックを書き込みました。 次に、MasterAはMasterBからバイナリログを読み取ろうとしますが、パケットが大きすぎるため、レプリケーションが中断します。 いいえ、replicate_same_server_idは有効ではありません。



read_buffer_sizeとこのバグの関係は何ですか?


繰り返しますが、言葉で説明するよりも例を挙げたほうが良いでしょう。 新しい値を取得します。



max_allowed_packet = 32M

read_buffer_size = 16M








LOAD DATA INFILEを再度実行すると、両方のサーバーの出力は次のようになります。



#Begin_load_query: file_id: 1 block_len: 16777216

#Append_block: file_id: 1 block_len: 16777216

#Append_block: file_id: 1 block_len: 16777216

#Append_block: file_id: 1 block_len: 16777216

#Append_block: file_id: 1 block_len: 16777216

#Append_block: file_id: 1 block_len: 16777216

#Append_block: file_id: 1 block_len: 16777216

#Append_block: file_id: 1 block_len: 16777216

#Append_block: file_id: 1 block_len: 14614912








最大データブロックサイズはread_buffer_sizeの値に基づいているため、今では確実にmax_allowed_pa​​cketより大きくなることはありません。

したがって、read_buffer_sizeの値がmax_allowed_pa​​cketより大きい場合、MySQLへのデータのインポート中にレプリケーションエラーが発生する可能性があることを覚えておく価値があります。 このバグは、5.0.xから最新の5.5.25までのすべてのバージョンに存在し、これを回避する最も簡単な方法は、read_buffer_sizeをmax_allowed_pa​​cket以上に設定しないことです。 バグ30435は実際には修正されいないようです。



また、read_buffer_sizeの値を大きくしてもパフォーマンスが向上しないことを忘れないでください(この点については、元の記事で読むことができますが、 ここでは翻訳です)。



All Articles