MySQL主从同步报error 1236
发布时间:2022-04-06 10:54:29 所属栏目:MySql教程 来源:互联网
导读:【一】前言:作为MySQL的数据库管理员经常会碰到主从同步的问题,比较常见的有error 1236的报错。刚好最近又碰到了这个报错,以下是整理的文档; 【二】问题说明 1、环境信息 mysql 版本:5.7.20 操作系统版本:centeros 6.5 2、报错信息 点击(此处)折叠或
【一】前言:作为MySQL的数据库管理员经常会碰到主从同步的问题,比较常见的有error 1236的报错。刚好最近又碰到了这个报错,以下是整理的文档; 【二】问题说明 1、环境信息 mysql 版本:5.7.20 操作系统版本:centeros 6.5 2、报错信息 点击(此处)折叠或打开 mysql> show slave statusG; *************************** 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这种开源的产品后续报错的提示需要更清楚一点,管理起来也会轻松很多。 (编辑:包头站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
站长推荐