实战处理mysql主从延时不一致之手动修复

  前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