背景

之前搭建了主從，但沒有設定讀寫分離，從庫也能寫資料。於是想測試下在從庫寫資料會導致同步怎麼樣。 結果發現，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. 其實按道理一般不會出現主從不同步的情況，因為主從需要搭配讀寫分離來弄。從庫既然只能讀，那就不存在主從不同步的情況了。