mysql 1197_mysql主从不同步报错Last_Errno 1197
?Last_Errno: 1197
? ? ? ? ? ? ? ? ? ?Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '6a878476-2f48-11ee-a6ca-00155d28f50c:1345602840' at source log mysql-bin.016873, end_log_pos 2585035600. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
mysql报警主从不同步,查看发现是sql_running断了
问题分析:
有一个表大概有20W条数据开发要对它进行操作,提前在主库直接复制备份了一份
可能是数据量太大,一时无法处理
排查方式
首先我们先通过 performance_schema 查看一下造成报错的原因
mysql> select * from performance_schema.replication_applier_status_by_worker;
有些比较明显的问题系统会给出一些建议的解决方案,大多是跟着系统说得做就好了。
mysql> show variables like '%max_binlog_cache_size'; +-----------------------+-----------+ | Variable_name | Value | +-----------------------+-----------+ | max_binlog_cache_size | 134217728 | +-----------------------+-----------+ 1 row in set (0.00 sec) sql = "show global variables like 'max_binlog_cache_size';" 40G # sql ='set global max_binlog_cache_size=40*1024*1024*1024;' mysql> set global max_binlog_cache_size=40*1024*1024*1024; Query OK, 0 rows affected (0.00 sec) mysql> stop slave; Query OK, 0 rows affected (0.02 sec) mysql> start slave; Query OK, 0 rows affected (0.01 sec) mysql> show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.120.141.228 Master_User: sys_repl Master_Port: 3306 Connect_Retry: 10 Master_Log_File: mysql-bin.000247 Read_Master_Log_Pos: 39371887 Relay_Log_File: mysqld-relay-bin.000064 Relay_Log_Pos: 213210879 Relay_Master_Log_File: mysql-bin.000242 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: 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: 213210706 Relay_Log_Space: 4892658324 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: 1993751 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 141228 Master_UUID: 3dda54fe-bac1-11e7-920c-0050569f4477 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Reading event from the relay log Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: cacca550-aa66-11e8-950f-525400b9c881:1-11, fcfab99d-a492-11e5-be37-0050569f3992:1 Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec)
?这样就OK了
max_binlog_cache_size
如果事务需要内存超过此字节数,服务器生成如下错误ERROR 1197 (HY000): Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage;max_binlog_cache_size
最低值是4096,最大可能值为16EB(艾字节)。推荐的最大值为4GB ;因为目前的MySQL当二进制日志位置大于4GB时并不生效。
Note:
Prior to MySQL 5.6.7, 64-bit Windows platforms truncated the stored value for this variable to 4G, even when it was set to a greater value (Bug #13961678).
在MySQL 5.6 ,会话对于max_binlog_cache_size的感知依赖于binlog_cache_size系统变量;换句话说,改变其值只会影响后续新建会话。
max_binlog_size
如果写二进制日志导致当前日志文件大小超过了这个变量的值时,服务器旋转二进制日志(关闭当前的文件,并打开下一个) 。的最小值为4096字节。最大值和默认值是1GB 。
事务是以块为单位写入二进制日志的,因此它不会被拆分在几个二进制日志。如果你有大的交易,你可能会看到比max_binlog_size较大的二进制日志文件。
如果max_relay_log_size为0,max_binlog_size的值会被应用到中继日志。
max_binlog_stmt_cache_size
如果一个事务中的非事务性的语句需要大于这个数量的更多的内存,服务器会产生报错。最低值是4096 ,在32位平台最大和默认值是4GB。在64位平台最大和默认值是416EB(艾字节)。
Note
Prior to MySQL 5.6.7, 64-bit Windows platforms truncated the stored value for this variable to 4G, even when it was set to a greater value (Bug #13961678).
max_binlog_cache_size针对事务语句,max_binlog_stmt_cache_size针对非事务语句,当我们发现Binlog_cache_disk_use或者Binlog_stmt_cache_disk_use比较大时就需要考虑增大cache的大小
事务性语句&非事务性语句
在事务性语句执行过程中,服务器将会进行额外的处理,在服务器执行时多个事务是并行执行的,为了把他们的记录在一起,需要引入事务缓存的概念。在事务完成被提交的时候一同刷新到二进制日志。 对于非事务性语句的处理。遵循以下3条规则:
- 如果非事务性语句被标记为事务性,那么将被写入事务缓冲。
- 如果没有标记为事务性语句,而且事务缓存中没有,那么直接写入二进制日志。
- 如果没有标记为事务性语句,但是事务缓存中有,那么写入事务缓冲。
注意如果在一个事务中有非事务性语句,那么将会利用规则2,优先将该影响非事务表语句直接写入二进制日志。
如果一切正常,当事务中执行事务语句(DML)的时候,所以这些语句形成的event都会被记录到缓存里面,等到commit事务以后,这个缓存的数据会立即被刷入磁盘上的binlog文件里面,之后通过slave请求发送到slave,在slave重复执行。
顺便提一下,mysql的binlog里面的事务都是相互独立按顺序排列的。
现在开始假设意外的发生。
正常意外一:事务执行中rollback了。
如果在一个事务中,所有执行的语句都是在innodb表上执行(对于多个事务引擎如tokudb等并用尚未测试),直接执行rollback,会导致mysql直接清除缓存,不会写入任何event记录到binlog。
正常意外二:事务执行中使用了非事务表(myisam),然后rollback了。
在一个事务中,即有事务表,也有非事务表,如果正常执行,则没有任何问题,当如果在非事务表上的修改执行了,复制设置为statement的时候,binlog会把所有执行的event全部记录下来写入日志,包括事务与非事务语句,然后在最后面加上rollback。如果复制格式设置为row,那么所有事务表相关的数据都会被清理掉,而非事务表上的数据会被标记为已提交事务写入binlog。
正常意外三:事务执行顺序如下:事务语句1-》非事务语句2-》save point -》事务语句3 -》 rollback to savepoint -》 事务语句4 -》提交
对于上面的情况,statement情况下,所有执行的语句包括savepoint与rollback都会按顺序被记录到binlog。row情况下,非事务语句与事务语句是分别记录到binlog中,非事务执行event会全部被记录,事务执行event会连带savepoint与rollback都记录下来。
正常意外四:事务执行顺序如下:事务语句1-》savepoint-》非事务语句2-》事务语句3-》rollback to savepoint-》事务语句4 -》 commit
同上。
异常意外一:master正常提交了,但是在slave执行失败了。
master执行完成,提交之后,slave接收到relay然后执行,执行期间由于意外原因失败了。这个时候,statement格式下,mysql会重新回到事务begin处重新执行,如果再次失败的话就会报错。row模式下情况类似,区别在于,如果是包含非事务表执行的事务,非事务表上的event不会被重新执行。
参考
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!