Mysql 主从同步 slave_sql_running 为no

背景

之前搭建了主从，但没有设置读写分离，从库也能写数据。于是想测试下在从库写数据会导致同步怎么样。 结果发现，slave_sql_running为no，slava_IO_running仍然为yes.

原因

由于从库写数据，导致主从数据不一致，如果在主库写入和从库同样的数据，会导致sql线程终止，查看mysql错误日志如下：

2020-08-01T10:58:19.623077Z 135 [ERROR] Slave SQL for channel '': Could not execute Write_rows event on table shy_dep.zp_test; , Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000001, end_log_pos 882496, Error_code: 1062
2020-08-01T10:58:19.623101Z 135 [Warning] Slave: Error_code: 1062
2020-08-01T10:58:19.623110Z 135 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000001' position 882218

解决方法一

1. 在从库停掉slave同步，执行 stop slave;
2. 主库执行 SHOW MASTER STATUS，记录下File和Position的值
3. 从库根据主库的position位置重新连接进行同步

CHANGE MASTER TO master_host = '192.168.164.84',
MASTER_PORT = 3306,
master_user = 'root',
master_password = 'root',
master_log_file = 'mysql-bin.000001',
master_log_pos = 902262;#这里记录master最新的position

4. 从库启动同步， start slave;

通过以上步骤，可以实现主从重新开始同步。

PS: 这里在重新启动从库同步时，假设主库没有进行写操作。因为如果进行了写操作，则刚才记录的主库position位置可能会变。

所以一般需要把主库临时加锁不让写。

解决方法二

在从库执行以下命令：

stop slave;

set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

start slave;

SHOW SLAVE STATUS

经测试，以上方法也可以。

个人体会

用解决方法一存在一个问题。比如在从库写入一条数据11， 在主库写入一条数据12，我们知道由于主从不同步会导致slave_sql_running停了。如果通过第一种方法重新连接启动后，再把12这条数据删除，会报以下错误：

2020-08-01T11:00:38.853703Z 17564 [ERROR] Slave SQL for channel '': Could not execute Delete_rows event on table shy_dep.zp_test; Unknown error 1032, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000001, end_log_pos 883098, Error_code: 1032
2020-08-01T11:00:38.853717Z 17564 [Warning] Slave: Unknown error 1032 Error_code: 1032
2020-08-01T11:00:38.853721Z 17564 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000001' position 882828

从库由于找不到12这条记录进行删除从而会终止slave_sql_running这个线程，需要再重新连接主库的binlog最新位置进行同步。

而解决方法二，即使删除了12这条记录，仍然会保持同步。所以这里给我感觉是，第二种方式要好一些。

set global sql_slave_skip_counter=N #这里的N是指跳过N个event

官方解释：

This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.

个人理解，就是跳过当前从master中不能执行的事件

总结

1. 这里列出了主从不同步两种解决方案，测试发现第二种解决方案好一些.
2. 其实按道理一般不会出现主从不同步的情况，因为主从需要搭配读写分离来弄。从库既然只能读，那就不存在主从不同步的情况了。