前2天经常被同事反应crm后台系统和前台，经常报前后查询不一致的问题。一开始也很抓狂，从集群、日志跟踪、网络转包等方面排查，都没找到原因，后来经过和研发同事一起沟通，提出线上mysql主从数据库可能不一致导致，于是立马登陆mysql主从服务器，查看复制状态，到这很明显问题就找到。
手动修复主从延时不一致，主库完整mysqldump导出，注意用的参数。经过实践，是线上成功修复主从不一致的结果哦。还有个奇葩的问题，就是刚修复主从不一致，很快又出现，延时又拉很大。到这你是否会想到，主库有大量数据的写入，从库复制过来就会越来越慢，我当时检查系统的crontab，果真发现有自动脚本，会把线下数据库大量数据同步到主库。要想彻底解决问题，思路很重要啊，看来。后面会继续发博客之在线检查及修复，敬请关注。
看你的mysql现在已提供什么存储引擎:
mysql> show engines;
看你的mysql当前默认的存储引擎:
mysql> show variables like ‘%storage_engine%‘;
你要看某个表用了什么引擎(在显示结果里参数engine后面的就表示该表当前用的存储引擎):
mysql> show create table 表名;
1. 从主服务器得到一个快照版本
如果你的是MYISAM或者既有MYISAM又有INNODB的话就在主服务器上使用如下命令导出服务器的一个快照：并把文件拷贝到从数据库上
mysqldump -uroot -p --default-character-set=gbk --add-locks --lock-tables --lock-all-tables --events --triggers --routines --flush-logs --master-data=2 --databases 51auto_v4 >db.sql
试过只有INNODB的话就是用如下命令：并把文件拷贝到从数据库上
mysqldump -uroot -p --default-character-set=gbk --single-transaction --events --triggers --routines --flush-logs --master-data=2 --databases 51auto_v4 > db.sql
这里需要注意几个参数的使用：
--single-transaction 这个参数只对innodb适用。
--databases 后面跟除mysql以后的其他所有数据库的库名，
--master-data 参数会记录导出快照时候的mysql二进制日志位置，一会会用到。
2. 将快照版本还原到从服务器上
mysql -uroot -p 51auto_v4 < db.sql
将快照版本还原到从服务器上以后，此时从服务器上的数据和主服务器的数据是一致的。
3. 在从服务器上生成CHANGE MASTER语句： 使用grep命令查找到二进制日志的名称以及位置
# grep -i "change master" db.sql
-- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.002515‘,
4. STOP SLAVE;
5. RESET SLAVE;
6. 执行change master
#从库5.12上执行
CHANGE MASTER TO MASTER_HOST=‘172.31.5.11‘,MASTER_USER=‘repuser‘,MASTER_PASSWORD=‘51auto‘,MASTER_LOG_FILE=‘mysql-bin.002515‘, MASTER_LOG_POS=894830515;
#从库5.13上执行
CHANGE MASTER TO MASTER_HOST=‘172.31.5.11‘,MASTER_USER=‘copy‘,MASTER_PASSWORD=‘51auto‘,MASTER_LOG_FILE=‘mysql-bin.002515‘, MASTER_LOG_POS=894830515;
7. START SLAVE;
8. SHOW SLAVE STATUS\G;查看Slave_IO_Running和Slave_SQL_Running的状态，如果都为Yes，就大功告成了。
本文出自 “hanyun.fang” 博客，请务必保留此出处http://hanyun.blog.51cto.com/1060170/1621755
原文地址：http://hanyun.blog.51cto.com/1060170/1621755
