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

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

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

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

查看从库状态：

mysql> show slave status\G;

显示

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 版权声明：本文为博主原创文章，转载请附上博文连接！