Mysql主从不一样步问题处理案例

在使用Mysql的主从复制架构中，有两个比较头疼的问题：

一、主从数据不一样步后如何处理

二、主从同步延迟问题如何解决

 

本文将根据实际案例来分析下问题1，至于问题2多数文档介绍的办法是启用多线程复制来解决，言归正传，这里的问题1还能够细分红两种状况。

一、Slave_IO_Running和Slave_SQL_Running在YES情况下，主从数据不一样步如何处理？

二、Slave_SQL_Running在NO状况下，主从数据不一样步如何处理？

 

出现第一种状况一般缘由是手工去修改了从库的数据致使主从数据不一致，这种状况若是不及时处理，当主库也更新了对应的数据的时候，就会演变为第二种状况。

 

举个例子：

在一主一从的条件下，当前主从的数据是同步的。

人为去操做从库的某张表数据,本例中以asm_user表为演示，其中id字段为主键

mysql> insert into test.asm_user (id,name,salary) values (1,'a',10000);

当主库的这条数据未变更的时候，当前主从同步进程中Slave_IO_Running和Slave_SQL_Running仍是为YES，目前只是asm_user这张表的数据不一样步而已，对应其余schema上的数据仍是会保持主从同步；

 

但若是这个状况，主库执行相同的SQL语句：

mysql> insert into test.asm_user (id,name,salary) values (1,'a',10000);

对应的SQL apply到从库的时候就会发现duplicate key,这个时候主从的同步就会中止掉。

# tail -f /home/mydata/localhost.localdomain.err

这种状况下，通常咱们采用maatkit工具来校验主从数据库的数据差别状况。

这个办法其实回答了前面的问题1，Slave_IO_Running和Slave_SQL_Running在YES状况下，主从数据不一样步如何处理？

# yum -y install perl-TermReadKey 
# wget ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/maatkit-7540.tar.gz
# tar -zxvpf maatkit-7540.tar.gz 
# cd maatkit-7540
# perl Makefile.PL 
# make && make install
# mk-table-checksum h=192.168.115.6,u=root,p=123456,P=3306  \
h=192.168.115.7,u=root,p=123456,P=3306 -d test | mk-checksum-filter
# mk-table-checksum h=192.168.115.6,u=root,p=123456,P=3306 \
h=192.168.115.7,u=root,p=123456,P=3306 -d test

若是主从数据不一致则采用mk-table-sync进行数据同步

# mk-table-sync --execute --print --no-check-slave --transaction --databases test  \
h=192.168.115.6,u=root,p=123456 h=192.168.115.7,u=root,p=123456

很明显当前test库数据是一致的，目前主从同步这个错误是能够忽略的，所以咱们采用跳过这个事务的办法来处理主从数据库不一样步问题。一般在生产环境中，主库的数据是不断的更新的，这里咱们在主从数据不一样步的状况下在主库继续插入一条数据，方便后续验证。

下面咱们开始处理主从不一样步问题：

在未启用GTID复制的状况下采用下面的方法跳过事务：

mysql>slave stop; 
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;  //跳过一个事务 
mysql>slave start;

Mysql5.6以后支持GTID复制，开启GTID复制的好处不少，具体能够百度一下！但当开启gtid后就不能采用前面那种办法来跳过事务。

在show slave status \G;输出中的最后几条里面，

Retrieved_Gtid_Set项：记录了relay日志从Master获取了binlog日志的位置

Executed_Gtid_Set项：记录本机执行的binlog日志位置（若是是从机，包括Master的binlog日志位置和slave自己的binlog日志位置）

咱们要跳过事务的GTID在错误日志中有记录

# tail -f /home/mydata/localhost.localdomain.err

mysql> set session gtid_next='bd9e9912-2bc7-11e6-bade-000c29b8871c:1440';
mysql> begin;commit;
mysql> set session gtid_next=automatic;

mysql> start slave;
mysql> show slave status \G;

验证从库数据是否和主库一致

mysql> select * from test.asm_user;

前面模拟了Slave_SQL_Running在NO状况下，主从数据不一样步状况的处理过程，在现实的环境中，每每状况要复杂的多，下面分享一则内存开发库由于断电致使主从数据不一致的故障处理：

一、由于电源故障，致使主从数据库所有宕机，电源恢复后，主库启动正常，从库没法启动，经过分析日志发现多是电源故障致使从库的固态盘异常，许多的binlog文件权限出现？？？，这些文件甚至没法正常查看

一、经过fsck -y进行文件系统校验修复坏块，修复完成后从库数据库能够启动，但开启复制进程的时候报中继日志丢失

二、在没有办法的状况下，采用主库dump数据，从库从新source的办法在线重作主从数据同步。整个操做过程当中，主库的数据不断的写入。

 

下面是大体的步骤：

3.1、主库导出全库数据，注意必定要使用--single-transaction参数

# /usr/local/mysql/bin/mysqldump --all-databases --single-transaction --triggers --routines > /tmp/1.sql

3.2、将备份文件拷贝到从库进行source

3.3、开启从库的复制进程

mysql> change master to master_host='192.168.1.15',

master_user='rep1',master_password='123456',MASTER_AUTO_POSITION=1;

mysql> start slave;