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. 其实按道理通常不会出现主从不一样步的状况，由于主从须要搭配读写分离来弄。从库既然只能读，那就不存在主从不一样步的状况了。