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

蜜饯LHmysql数据双主同步异常_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⽇志分析
通过查看⽇志⽂件发现如下报错信息:
通过上⾯⽇志分析,发现双主同步复制异常存在两种情况:lora通信
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 byserial_no;
5.4导⼊修复好的表数据
再把new_026.sql数据导⼊数据库即可[mysql@vgasmrzfaceresource02 ~]$cat mysql_in.sh
mysql --login-path=myconn<
use smzrz;
set names utf8mb4;
select database();
set sql_log_bin=0;
source data/backup/new_026.sql
EOF
5.5校验数据
最终数据查询,如下查询已经恢复到原始数据量。
最后把这个表数据mysqldump到master01/master02数据库,再把双主复制功能恢复就可以了。
[故障总结]
此次故障恢复还是算流畅的,没有遇到较⼤的难点,数据库服务器恢复正常后,也通知业务侧那边进⾏数据校验,同时得到他们的认可数据恢复⼀致,没有问题再现。

本文发布于:2024-09-21 17:36:09,感谢您对本站的认可!

本文链接:https://www.17tex.com/tex/3/138940.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:数据   双主   复制   主键   数据库   冲突   发现
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2024 Comsenz Inc.Powered by © 易纺专利技术学习网 豫ICP备2022007602号 豫公网安备41160202000603 站长QQ:729038198 关于我们 投诉建议