mysql主从不同步问题 Error_code: 1197

首先查看从的状态

 

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: 39320676
               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: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   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 'ANONYMOUS' at master log mysql-bin.000242, end_log_pos 347537149. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 213210706
              Relay_Log_Space: 4892606739
              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: 0
                Last_IO_Error:
               Last_SQL_Errno: 1197
               Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' at master log mysql-bin.000242, end_log_pos 347537149. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
  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:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 181024 16:18:24
               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)

 

提示已经很明显了，让查看performance_schema.replication_applier_status_by_worker这个表看详细的问题

 

mysql> select * from performance_schema.replication_applier_status_by_worker\G
*************************** 1. row ***************************
         CHANNEL_NAME:
            WORKER_ID: 1
            THREAD_ID: NULL
        SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: ANONYMOUS
    LAST_ERROR_NUMBER: 1197
   LAST_ERROR_MESSAGE: Worker 1 failed executing transaction 'ANONYMOUS' at master log mysql-bin.000242, end_log_pos 347537149; 

　　　　　　　　　　　　　　Could not execute Delete_rows event on table pipeline.m_orderitem; 

                        Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; 

                        increase this mysqld variable and try again, Error_code: 1197; handler error HA_ERR_RBR_LOGGING_FAILED; 

                        the event's master log mysql-bin.000242, end_log_pos 347537149

 LAST_ERROR_TIMESTAMP: 2018-10-24 16:18:24

 

有些比较明显的问题系统会给出一些建议的解决方案，大多是跟着系统说得做就好了。

 

mysql> show variables like '%max_binlog_cache_size';
+-----------------------+-----------+
| Variable_name         | Value     |
+-----------------------+-----------+
| max_binlog_cache_size | 134217728 |
+-----------------------+-----------+
1 row in set (0.00 sec)

mysql> set global max_binlog_cache_size=10737418240;
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条规则：

1. 如果非事务性语句被标记为事务性，那么将被写入事务缓冲。
2. 如果没有标记为事务性语句，而且事务缓存中没有，那么直接写入二进制日志。
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不会被重新执行。

参考

Binary Log Options and Variables

max_binlog_stmt_cache_size

mysql复制对事务的处理

mysql二进制日志处理事务与非事务性语句的区别