数据库主库从库宕机重启后binlog数据同步

由于阿里云经典网络迁移到专用网络，一不小心没有先预备方案调整网段，导致实例无法以内网IP形式访问数据库，被迫进行数据库停机后网络网段调整，导致宕机了几个小时。。。被客户各种投诉爆了。。

基于这次数据库恢复血泪史，特整理解决办法，让日后同学避免再犯。

数据库master库重启后，确保能正常提供服务。由于生产上BI系统使用的是slave从库做数据查询，从库的数据库已经落后了master好几天，

查看从库状态：

mysql> show slave statusG;

显示

Slave_IO_Running: No
Slave_SQL_Running: No

说明从库尚未启动数据库同步，由于几天的binlog的数据量太大，找binlog开始位置找了好久没找到，索性先把当前的master数据库导出一份拷贝到从库，按照导出的时间找binlog位置点。

使用 mysqldump 命令导出整个master 到文件 hairdonkey.sql.2018-07-20

从库先删除后新增

# 删除从库的数据库
drop database hairdonkey;
# 创建新数据库
CREATE DATABASE `hairdonkey` /*!40100 DEFAULT CHARACTER SET utf8mb4 */;
# 导入备份的数据
use hairdonkey;
source /data/db_backup/master/hairdonkey.sql.2018-07-20
# 用户授权
grant select, delete, insert, update on hairdonkey.* to onlyreader@'172.%';
flush privileges;

从库导入完毕后，开始关键的一步：找binlog开始同步的位置！

查询binlog位置

（数据库中表数据新增最频繁的表是关键短信发送日志表sms_message_log，每秒1-2条的频率，故查从库的sms_message_log表的最后一条记录的插入时间！）：

1. 导出sms_message_log表：

/data/mysql/bin/mysqldump --socket=/data/mysql/mysql.sock -h172.17.120.167 -uhairdonkey -p123 -B hairdonkey --table sms_message_log --opt --extended-insert=false --single-transaction > sms_message_log.sql;

2.vim 编辑sms_message_log.sql 把 sms_message_log 全部替换为 mid_sms_message_log

把主表的sms_message_log数据导入到从库中的中间表 mid_sms_message_log (替换命令： :%s/sms_message_log/mid_sms_message_log/g )

3. 执行sql :

source /data/work/sms_message_log.sql

4. 查询mid_sms_message_log比从库多的数据，并倒叙排列：

select * from hairdonkey.mid_sms_message_log a where not exists(
select 1 from sms_message_log b where a.id = b.id
) order by id desc;

记录max(id) as maxSmsId, min(id) as minSmsId

5. 查看短信发送时间字段 send_tm 的最大最小值，导出这个时间区间的Binlog:

mysqlbinlog -uhairdonkey -p123 -P3306 -h172.17.120.167 --start-datetime="2018-07-21 19:55:40" --stop-datetime="2018-07-21 19:55:59" --read-from-remote-server -vv mysql-bin.000772 >row3.sql

6. 编辑模式打开row3.sql, 查找短信记录表minSmsId所在的位置的insert sql对应的endPos 记为 minEndPos,

maxSmsId 所在的位置的insert sql对应的endPos 记为 maxEndPos

导出这两个区间的binlog:

mysqlbinlog -uhairdonkey -p123 -P3306 -h172.17.120.167 --start-position="875932395" --stop-position="878561125" --read-from-remote-server -vv mysql-bin.000772 >row2.sql

7. 运行row2.sql: source /data/work/row2.sql

8. 比较mid_sms_message_log和从库的sms_message_log表数据，应该是已经数量一致了

9. 设置从库同步位置点(这个点就是maxEndPos)：

(1)停止从库同步：stop slave;

(2) 修改master信息：

change master to master_host='172.17.120.167',master_user='hairdonkey',master_password='123',master_log_file='mysql-bin.000772',master_log_pos=875845853;

(3) 启动从库：start slave;

(4) 查看从库状态：show slave status G;

看到如下两个为Yes，说明同步成功！

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

附加：

mysql主从复制，经常会遇到错误而导致slave端复制中断，这个时候一般就需要人工干预，跳过错误才能继续
跳过错误有两种方式：
1.跳过指定数量的事务：
mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 #跳过一个事务
mysql>slave start

2.修改mysql的配置文件，通过slave_skip_errors参数来跳所有错误或指定类型的错误
vi /etc/my.cnf
[mysqld]
#slave-skip-errors=1062,1053,1146 #跳过指定error no类型的错误
#slave-skip-errors=all #跳过所有错误
---------------------
作者：seteor
来源：CSDN
原文：https://blog.csdn.net/seteor/article/details/17264633
版权声明：本文为博主原创文章，转载请附上博文链接！