Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


17.4.1.20 レプリケーションと max_allowed_packet

max_allowed_packet は、MySQL サーバーとクライアント (レプリケーションスレーブを含みます) の間の単一メッセージのサイズに上限を設定します。大きなカラム値 (TEXT または BLOB カラムで見つかる場合があります) を複製していて、max_allowed_packet がマスター上で小さすぎる場合は、マスターがエラーで失敗し、スレーブは I/O スレッドをシャットダウンします。max_allowed_packet がスレーブ上で小さすぎる場合も、スレーブは I/O スレッドを停止します。

行ベースレプリケーションは現在、更新された行のすべてのカラムとカラム値をマスターからスレーブに送信します (更新で実際には変更されなかったカラムの値を含みます)。これは、行ベースレプリケーションを使用して大きなカラム値を複製するときに、複製されるテーブル内でもっとも大きい行を格納できるだけの大きさに max_allowed_packet を設定するように気をつける必要があります (更新だけを複製したり、比較的小さい値だけを挿入したりする場合でも)。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
  Posted by Tim Jones on November 2, 2012
Ran into a bit of an issue updating max_allowed_packet dynamically on a master/slave pair. I thought I was being smart by updating the slave setting first and then the master but that's not quite enough. The slave immediately reported:

"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'"

After a slave start I got this:

"Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave."

Yikes!. The good news is that it's just your relay logs that are borked, not the master logs. I think this may have something to do with the fact that the max_allowed_packet is not updated for existing connections, only new ones, and the slave needs a bit of a bump to keep it going properly (?).

The solution is to reconfigure the connection to the slave with the RELAY_MASTER_LOG_FILE AND EXEC_MASTER_LOG_POS from SHOW SLAVE STATUS. You just need to plug RELAY_MASTER_LOG_FILE and EXEC_MASTER_LOG_POS into MASTER_LOG_FILE AND MASTER_LOG_POS a CHANGE MASTER TO statement and things should be good to go. Note that you only need to specify those two values (no need to include host, password, etc) as the existing settings will be reused by default.

Credit to http://ebergen.net/wordpress/2010/11/09/max_allowed_packet-replication-and-global-variables/