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

創(chuàng)新互聯(lián)專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、錦江網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5技術(shù)、商城網(wǎng)站制作、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為錦江等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

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

問題的現(xià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'

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

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

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

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

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

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

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

演練：
構(gòu)造測試用的表

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

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

數(shù)據(jù)：

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

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ān)閉一個從庫的SQL_thread來模擬延時(shí)從庫，（從主庫拉取binlog，但是這些binlog的內(nèi)容沒有在從庫復(fù)現(xiàn)，類似于保持X分鐘前的狀態(tài)）


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


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


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

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


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


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


可以看到slave執(zhí)行完了533和534之后，沒有執(zhí)行535，然后停下來了，看看從庫的表數(shù)據(jù)，可以發(fā)現(xiàn)數(shù)據(jù)正好在錯誤的語句之前，


接下來就比較簡單了， 把表數(shù)據(jù)導(dǎo)出來，然后在主庫上恢復(fù)；

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

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

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

“MySQL主從同步問題和延時(shí)從庫的"閃回"是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！