MySQL主從同步問題和延時從庫的"閃回"是什么

本篇內容介紹了“MySQL主從同步問題和延時從庫的"閃回"是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

背景：折騰MySQL-5.7.9的副產品；所有的演練和操作都是基于5.7.9，和5.6.2x應該不會有什么區別

問題的現象：Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replica'

問題發生的原因：在從庫start slave時出現錯誤；

問題分析：
主從同步還是依靠日志來完成的，出現這種問題的原因就是從庫的slave_master_info中的信息與主庫的狀態不一致， slave_IO_thread依靠從庫的slave_master_info信息，去主庫上“繼續”dump binlog的時候，找不到數據了；

問題解決的方法：
1.change master的時候， 指明一個確定的log_file和log_pos，不要圖方便用auto_position；
2.確定主從當前的數據是完全一致的情況下（主庫處于只讀狀態or完全停庫狀態），在slave和master上reset master， 清理掉所有的日志， 然后用auto_position開啟新的同步；

方法1更加常用一些，畢竟停庫的機會基本不會有；
PS：在多源復制中，如果提示ERROR 3079 (HY000): Multiple channels exist on the slave. Please provide channel name as an argument. 需要用reset slave all去清空多個channel的信息；

-----------------------------------------------------------------------------------問題的延伸------------------------------------------------------------------------------------
提到從庫，之前取巧， 用單獨的延時從庫來實現閃回，出現問題后，如果涉及的數據比較少的時候，可以直接解析binlog去恢復（ROW），
如果涉及到的數據比較多（比如說沒有where的update http://blog.itpub.net/29510932/viewspace-1962834/）的時候，利用備份重新生成備庫，也會消耗相當多的時間；

延伸：如果存在延時從庫，該如何進行“閃回”/數據恢復？

分析&捕捉：
大前提，延時從庫還沒有執行那條錯誤的語句，那么在延時從庫上就存在著正確的數據，因此可以第一時間停掉slave_SQL_thread，然后控制slave_SQL_thread執行到特定的pos，再進行恢復；

演練：
構造測試用的表

點擊(此處)折疊或打開

1. CREATE TABLE `student` (
   

2.   `sid` bigint(20) NOT NULL,
   

3.   `sname` varchar(10) DEFAULT NULL,
   

4.   `col1` int(11) DEFAULT NULL,
   

5.   `col2` bigint(20) NOT NULL,
   

6.   `time` datetime NOT NULL DEFAULT '2015-11-11 00:00:00',
   

7.   PRIMARY KEY (`sid`),
   

8.   KEY `idx_c1_c2` (`col1`,`col2`),
   

9.   KEY `idx_c1_c2_si` (`col1`,`col2`,`sid`),
   

10.   KEY `idx_time` (`time`),
    

11.   KEY `idx_sname` (`sname`),
    

12.   KEY `idx_col2` (`col2`)
    

13. ) ENGINE=InnoDB DEFAULT CHARSET=utf8

數據：

點擊(此處)折疊或打開

1. INSERT INTO `student` VALUES (10000,'lily',9,10,'2015-11-11 00:00:01'),(10001,'lucy',11,1,'2015-11-01 00:00:01'),(10002,'tom',3,3,'2015-11-10 00:00:01'),(10003,'tommy',4,6,'2015-11-09 00:00:01'),(10004,'jhon',8,15,'2015-11-12 00:00:01'),(10005,'dave',14,27,'2015-11-02 00:00:01'),(10006,'charly',19,36,'2015-11-07 00:00:01'),(10007,'sam',23,21,'2015-11-08 00:00:01'),(10008,'titan',31,7,'2015-11-11 00:00:01'),(10009,'anny',27,12,'2015-11-10 00:00:01');

通過關閉一個從庫的SQL_thread來模擬延時從庫，（從主庫拉取binlog，但是這些binlog的內容沒有在從庫復現，類似于保持X分鐘前的狀態）


延時從庫的測試數據：


在主庫上進行操作，正確的語句執行完以后的效果：


錯誤的語句--沒有where的update

假設及時的發現了問題，且從庫并沒有復現這些語句，那么及時停掉從庫的SQL_thread，
就可以變成類似于測試環境的情況，查看從庫的狀態，可以看到接收到了新的binlog，但是從庫并沒有復現這些操作


回到主庫上，用mysqlbinlog來解析日志


可以看到535的事務是這個有問題的事務， 那么可以在從庫指定這個事務作為終止事務，
在命令行下輸入START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 'dfe44b6e-940a-11e5-89a6-005056a94f05:535';
指定 SQL_THREAD執行到535之前的事務，然后SQL_THREAD會自動停止，看一下slave的status


可以看到slave執行完了533和534之后，沒有執行535，然后停下來了，看看從庫的表數據，可以發現數據正好在錯誤的語句之前，


接下來就比較簡單了， 把表數據導出來，然后在主庫上恢復；

-----------------------------------------------------------------------------------額外的嘮叨------------------------------------------------------------------------------------
現實中的情況永遠要復雜很多，如果業務繁忙，在這個錯誤語句之后如果還有其他的業務在對這張表做操作的話，只做上文的步驟，就會有丟事務/業務操作的情形出現，這種情況下，就要準備折騰這個延時從庫了；

新的問題&需求：雖然執行了錯誤的語句，但是后續還是有業務相關的SQL產生，而且都很重要， 不能丟

解決的辦法：
直到上一步為止，剛好是讓延時從庫停在了錯誤的事務之前，為了能讓后續的操作不丟失，需要在延時從庫上生成一個空事務，跳過有問題的這個535事務，然后去掉延時從庫的延時，
等追上主庫的時候，這個表的數據就是完整的數據。

“MySQL主從同步問題和延時從庫的"閃回"是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！