在使用Mysql的主从复制架构中，有两个比较头疼的问题：
1、主从数据不同步后如何处理
2、主从同步延迟问题如何解决
本文将根据实际案例来分析下问题1，至于问题2多数文档介绍的办法是启用多线程复制来解决，言归正传，这里的问题1还可以细分成两种情况。
1、Slave_IO_Running和Slave_SQL_Running在YES情况下，主从数据不同步如何处理？
2、Slave_SQL_Running在NO情况下，主从数据不同步如何处理？
出现第一种情况通常原因是手工去修改了从库的数据导致主从数据不一致，这种情况如果不及时处理，当主库也更新了对应的数据的时候，就会演变为第二种情况。
举个例子：
在一主一从的条件下，当前主从的数据是同步的。
![wKioL1defkyRX4N5AAAsgdsSjK0970.png-wh_50]( "1.png")
人为去操作从库的某张表数据,本例中以asm_user表为演示，其中id字段为主键
mysql> insert into test.asm_user (id,name,salary) values (1,'a',10000);
![wKioL1defnOQRVV1AAAbXUTtCaw457.png-wh_50]( "2.png")
当主库的这条数据未变动的时候，当前主从同步进程中Slave_IO_Running和Slave_SQL_Running还是为YES，目前只是asm_user这张表的数据不同步而已，对应其他schema上的数据还是会保持主从同步；
但如果这个情况，主库执行相同的SQL语句：
mysql> insert into test.asm_user (id,name,salary) values (1,'a',10000);
![wKiom1defYWD6mNsAAAulN7mfCk568.png-wh_50]( "3.png")
对应的SQL apply到从库的时候就会发现duplicate key,这个时候主从的同步就会停止掉。
![wKioL1deg_aB1GSFAADVt0D2mrI706.jpg-wh_50]( "1.jpg")
# tail -f /home/mydata/localhost.localdomain.err
![wKiom1degxHSg_fYAAHU5lGGFJE782.jpg-wh_50]( "1.jpg")
这种情况下，一般我们采用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
![wKioL1defwTiewiDAAAf3dxeEvM458.png-wh_50]( "6.png")
如果主从数据不一致则采用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库数据是一致的，目前主从同步这个错误是可以忽略的，因此我们采用跳过这个事务的办法来处理主从数据库不同步问题。通常在生产环境中，主库的数据是不断的更新的，这里我们在主从数据不同步的情况下在主库继续插入一条数据，方便后续验证。
![wKiom1defiiSepqiAAAHhCqI68I693.png-wh_50]( "7.png")
下面我们开始处理主从不同步问题：
在未启用GTID复制的情况下采用下面的方法跳过事务：
mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; //跳过一个事务
mysql>slave start;
Mysql5.6之后支持GTID复制，开启GTID复制的好处很多，具体可以百度一下！但当开启gtid后就不能采用前面那种办法来跳过事务。
![wKiom1defmHANpENAAAbbunNJGg135.png-wh_50]( "8.png")
在show slave status \G;输出中的最后几条里面，
Retrieved_Gtid_Set项：记录了relay日志从Master获取了binlog日志的位置
Executed_Gtid_Set项：记录本机执行的binlog日志位置（如果是从机，包括Master的binlog日志位置和slave本身的binlog日志位置）
![wKiom1defnejlgvOAABIDzTvZPo455.png-wh_50]( "9.png")
我们要跳过事务的GTID在错误日志中有记录
# tail -f /home/mydata/localhost.localdomain.err
![wKiom1defp6BFAf4AABxhFEkNRE916.png-wh_50]( "10.png")
mysql> set session gtid_next='bd9e9912-2bc7-11e6-bade-000c29b8871c:1440';
mysql> begin;commit;
mysql> set session gtid_next=automatic;
![wKiom1defruipUhkAAAWDyHizeU551.png-wh_50]( "11.png")
mysql> start slave;
mysql> show slave status \G;
![wKiom1deftez44ZfAAAxVx15lp4238.png-wh_50]( "12.png")
验证从库数据是否和主库一致
mysql> select * from test.asm_user;
![wKioL1degAejA92LAAAJkqFK890385.png-wh_50]( "13.png")
前面模拟了Slave_SQL_Running在NO情况下，主从数据不同步情况的处理过程，在现实的环境中，往往情况要复杂的多，下面分享一则内存开发库因为断电导致主从数据不一致的故障处理：
1、因为电源故障，导致主从数据库全部宕机，电源恢复后，主库启动正常，从库无法启动，通过分析日志发现可能是电源故障导致从库的固态盘异常，许多的binlog文件权限出现？？？，这些文件甚至无法正常查看
![wKioL1degB-A0o4tAAIJHQ0T6_o437.png-wh_50]( "14.png")
1、通过fsck -y进行文件系统校验修复坏块，修复完成后从库数据库可以启动，但开启复制进程的时候报中继日志丢失
2、在没有办法的情况下，采用主库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;
