导航：首页 > 数据库 >

MySQL主从同步报error 1236

发表于：2025-02-04 作者：千家信息网编辑

千家信息网最后更新 2025年02月04日，【一】前言：作为MySQL的数据库管理员经常会碰到主从同步的问题，比较常见的有error 1236的报错。刚好最近又碰到了这个报错，以下是整理的文档；【二】问题说明1、环境信息mysql 版本：5.7

千家信息网最后更新 2025年02月04日MySQL主从同步报error 1236【一】前言：作为MySQL的数据库管理员经常会碰到主从同步的问题，比较常见的有error 1236的报错。刚好最近又碰到了这个报错，以下是整理的文档；

【二】问题说明
1、环境信息
mysql 版本：5.7.20
操作系统版本：centeros 6.5
2、报错信息

点击(此处)折叠或打开

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.1.19
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000123
Read_Master_Log_Pos: 221693972
Relay_Log_File: DB-02-relay-bin.000011
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000123
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB: DB02
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 221693972
Relay_Log_Space: 535
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
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.000123' at 221693972, the last event read from '/data/binlog/mysql-bin.000123' at 123, the last byte read from '/data/binlog/mysql-bin.000123' at 221693991.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 11
Master_UUID: b688e640-f5d3-11e7-9275-005056a675fe
Master_Info_File: /data/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 180705 23:22:44
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: b688e640-f5d3-11e7-9275-005056a666fe:1
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:

【三】问题原因
Slave_IO_Running: No
Slave_SQL_Running: Yes
通过以上两个参数可以知道，当前binlog主库传送到从库的时候就报错了。已经传送过来的binlog是可以正常执行的。

Last_IO_Error：max_allowed_packet显示当前参数过小需要进行增加。
max_allowed_packet控制着主从复制过程binglog event传送的大小，一般以下两种情况主从就会报错
1、参数在主备库的配置大小不一样，主库的配置值大于从库的配置值。从主库传递到备库的binlog event大小超过了主库或者备库的max_allowed_packet大小。
2、主库有大量数据写入时，比如insert into .... select 语句，产生大事务。
当主库向从库传递一个比从库的max_allowed_packet 大的packet ，从库接收该packet失败，并报 "log event entry exceeded max_allowed_packet"。

关于这个参数可以查看mysql的官方文档：
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_max_allowed_packet

Property	Value
Command-Line Format	--max-allowed-packet=#
System Variable	max_allowed_packet
Scope	Global, Session
Dynamic	Yes
Type	integer
Default Value	4194304
Minimum Value	1024
Maximum Value	1073741824

该参数可以在session进行修改，最小1k，最大1GB,默认4M

【四】解决方法

点击(此处)折叠或打开

参数查看的方法
mysql> show VARIABLES like '%max_allowed_packet%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| max_allowed_packet | 1073741824 |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+
2 rows in set (0.00 sec)
不重启数据库的修改方法，但是修改之后要重新登陆mysql

set global max_allowed_packet =512*1024*1024
重启数据库的修改方法
或者修改my.cnf参数
[server]
slave_max_allowed_packet = 512M

修改完之后，重新进行stop slave，再start slave

但是这只是其中的一个情况，最近遇到了一个数据库发现max_allowed_packet参数已经进行了设置，但是无论如何主从也都不会同步。
最后发现由于用户的误操作，导致master_log_pos位置错了，需要重新调整。
change master to master_log_file='mysql-bin.006738', master_log_pos=107;

总结：经过一顿折腾总算搞定了，有时候报错信息很明显，但是怎么解决都处理不了，这时候管理员的经验就体现出来了。还有mysql这种开源的产品后续报错的提示需要更清楚一点，管理起来也会轻松很多。

很赞哦！