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

發(fā)布時間：2021-09-16 14:36:32 來源：億速云閱讀：129 作者：chen 欄目：MySQL數(shù)據(jù)庫

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

背景：折騰MySQL-5.7.9的副產(chǎn)品；所有的演練和操作都是基于5.7.9，和5.6.2x應該不會有什么區(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時出現(xiàn)錯誤；

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

問題解決的方法：
1.change master的時候，指明一個確定的log_file和log_pos，不要圖方便用auto_position；
2.確定主從當前的數(shù)據(jù)是完全一致的情況下（主庫處于只讀狀態(tài)or完全停庫狀態(tài)），在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的信息；

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

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

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

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

點擊(此處)折疊或打開

CREATE TABLE `student` (
`sid` bigint(20) NOT NULL,
`sname` varchar(10) DEFAULT NULL,
`col1` int(11) DEFAULT NULL,
`col2` bigint(20) NOT NULL,
`time` datetime NOT NULL DEFAULT '2015-11-11 00:00:00',
PRIMARY KEY (`sid`),
KEY `idx_c1_c2` (`col1`,`col2`),
KEY `idx_c1_c2_si` (`col1`,`col2`,`sid`),
KEY `idx_time` (`time`),
KEY `idx_sname` (`sname`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

數(shù)據(jù)：

點擊(此處)折疊或打開

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來模擬延時從庫，（從主庫拉取binlog，但是這些binlog的內(nèi)容沒有在從庫復現(xiàn)，類似于保持X分鐘前的狀態(tài)）
MySQL主從同步問題和延時從庫的"閃回"是什么

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

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

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

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

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

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

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

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

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

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

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