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主从同步问题和延时从库的"闪回"是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注编程网网站，小编将为大家输出更多高质量的实用文章！