MySQL主從同步問(wèn)題和延時(shí)從庫的"閃回"是什

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

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

問(wèn)題的現象：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'

問(wèn)題發(fā)生的原因：在從庫start slave時(shí)出現錯誤；

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

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

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

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

延伸：如果存在延時(shí)從庫，該如何進(jìn)行“閃回”/數據恢復？

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

演練：
構造測試用的表

點(diǎn)擊(此處)折疊或打開(kāi)

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

數據：

點(diǎn)擊(此處)折疊或打開(kāi)

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');

通過(guò)關(guān)閉一個(gè)從庫的SQL_thread來(lái)模擬延時(shí)從庫，（從主庫拉取binlog，但是這些binlog的內容沒(méi)有在從庫復現，類(lèi)似于保持X分鐘前的狀態(tài)）


延時(shí)從庫的測試數據：


在主庫上進(jìn)行操作，正確的語(yǔ)句執行完以后的效果：


錯誤的語(yǔ)句--沒(méi)有where的update

假設及時(shí)的發(fā)現了問(wèn)題，且從庫并沒(méi)有復現這些語(yǔ)句，那么及時(shí)停掉從庫的SQL_thread，
就可以變成類(lèi)似于測試環(huán)境的情況，查看從庫的狀態(tài)，可以看到接收到了新的binlog，但是從庫并沒(méi)有復現這些操作


回到主庫上，用mysqlbinlog來(lái)解析日志


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


可以看到slave執行完了533和534之后，沒(méi)有執行535，然后停下來(lái)了，看看從庫的表數據，可以發(fā)現數據正好在錯誤的語(yǔ)句之前，


接下來(lái)就比較簡(jiǎn)單了， 把表數據導出來(lái)，然后在主庫上恢復；

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

新的問(wèn)題&需求：雖然執行了錯誤的語(yǔ)句，但是后續還是有業(yè)務(wù)相關(guān)的SQL產(chǎn)生，而且都很重要， 不能丟

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