数据库
首页 > 数据库> > MySQL数据库双主同步异常故障处理

MySQL数据库双主同步异常故障处理

作者:互联网

[概述]

在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用mysql主从方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动。因此,如果是双主或者多主,就会增加mysql入口,增加高可用。不过多主需要考虑自增长ID问题,这个需要特别设置配置文件,比如双主,可以使用奇偶,总之,主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题。

[故障背景]

Linux系统环境:SUSE12.4

MySQL数据库版本:5.7.29

Mysql数据库架构:双主

由于业务侧在做双主架构选择的时候,没有做VIP高可用冗余,所以只能实现普通的双主基本复制功能,分别基于maser01和master02之间的读写同步复制。


[故障发现]


生产中经监控平台发现MySQL数据库双主复制中SQL复制线程断开,经排查发现双主复制出现了异常,具体报错信息如下图所示:在master02数据库服务器上发现,同步master01数据库服务器的SQL线程断开了,截图如下:

图片


此时,检查master01数据库服务器的同步情况,发现master01同步master02的复制目前是正常显示的。

图片


[故障分析]


4.1日志分析

通过查看日志文件发现如下报错信息:

图片

通过上面日志分析,发现双主同步复制异常存在两种情况:

A:master01的表数据可能被truncate导致master02同步异常中断;


B:或者是master01和master02之间数据复制过程中主键冲突导致同步异常中断。最后我们来清查一下对应报错的表数据在master01和master02两个库中的数据是否一致,如果不一致,那就说明其中一个库中的数据被清理了,或者另一个库中的表数据同步一直不一致导致同步异常。


4.2表数据核对

1)经报错信息查询该表数据统计记录master02的表数据量为:462740条。

图片


2)同时也记录了master01数据库上,该表的数据量为:462733条。与master02对比发现数据量少了7条。

图片


4.3主键冲突

将master02上的这个表全表导出备份后,再将该表数据导入到master01中,最后还是报该表存在数据主键冲突,报错如下:

图片


[故障处理]


5.1表数据恢复

在导入过程中,需要关闭binlog的记录setsql_log_bin=0,避免导入数据表时报ID主键列冲突数据刷新到日志中,这样master01的表数据就会被master02的表数据全部置换,在主主同时写同时复制的情况下,之前一样的数据就没有了,最后剩下的是7条不一致的数据。虽然把主主复制功能恢复了,但是这个cer_work_order_temp表数据被新的二进制文件数据置换掉了,最终导致这表数据丢失。

图片


5.2全量和增量恢复

通过全备+增量备份在测试环境对cer_work_order_temp表进行数据恢复,先找到增量起始点position'812016541'结合二进制日志进行恢复该表在master02服务器上的数据。

图片


第一个binlog日志恢复命令如下:

mysql-bin.000025一次执行不完,分两次执行:

第一次:

mysqlbinlog --no-defaults --start-position="812016541" --stop-position="883789149" mysql-bin.000025 |mysql --login-path=myconn

第二次:

mysqlbinlog --no-defaults --start-position="883789256" mysql-bin.000025 |mysql --login-path=myconn


第二个binlog日志恢复命令如下:

因第二个日志mysql-bin.000026事务量比较大,如果像第一个binlog那样恢复的话,时间会很慢,所以第二个日志binlog我们采用sql文件导入方式:

根据发生的故障时间点,进行二进制日志数据的提取,提取方式如下所示:

mysqlbinlog   --stop-datetime='2020-07-07 23:59:59'   mysql-bin.000026   > new_026.sql


5.3主键修复

删除原表主键,再重建新表及1条索引,目的为了导入数据不冲突,并且导入速度快。

删除主键并建索引:

alter table cer_work_order_temp drop primary key;

create index aa on cer_work_order_temp(serial_no);

创建新的aa表并把cer_work_order_temp信息同步:

create table aa as

select *,count(distinct serial_no) from cer_work_order_temp group by serial_no;


5.4导入修复好的表数据

再把new_026.sql数据导入数据库即可

[mysql@vgasmrzfaceresource02 ~]$cat mysql_in.sh

mysql --login-path=myconn<<EOF

use smzrz;

set names utf8mb4;

select database();

set sql_log_bin=0;

source /data/backup/new_026.sql

EOF


5.5校验数据

最终数据查询,如下查询已经恢复到原始数据量。

图片

最后把这个表数据mysqldump到master01/master02数据库,再把双主复制功能恢复就可以了。


[故障总结]


此次故障恢复还是算流畅的,没有遇到较大的难点,数据库服务器恢复正常后,也通知业务侧那边进行数据校验,同时得到他们的认可数据恢复一致,没有问题再现。


标签:master01,master02,数据库,MySQL,--,mysql,数据,双主
来源: https://blog.51cto.com/u_15127668/2800492