在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用mysql主从方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加mysql入口，增加高可用。不过多主需要考虑自增长ID问题，这个需要特别设置配置文件，比如双主，可以使用奇偶，总之，主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题。
Linux系统环境：SUSE12.4
MySQL数据库版本：5.7.29
Mysql数据库架构：双主
由于业务侧在做双主架构选择的时候，没有做VIP高可用冗余，所以只能实现普通的双主基本复制功能，分别基于maser01和master02之间的读写同步复制。
生产中经监控平台发现MySQL数据库双主复制中SQL复制线程断开，经排查发现双主复制出现了异常，具体报错信息如下图所示：在master02数据库服务器上发现，同步master01数据库服务器的SQL线程断开了，截图如下：
此时，检查master01数据库服务器的同步情况，发现master01同步master02的复制目前是正常显示的。
通过查看日志文件发现如下报错信息：
通过上面日志分析，发现双主同步复制异常存在两种情况：
A：master01的表数据可能被truncate导致master02同步异常中断；
B：或者是master01和master02之间数据复制过程中主键冲突导致同步异常中断。最后我们来清查一下对应报错的表数据在master01和master02两个库中的数据是否一致，如果不一致，那就说明其中一个库中的数据被清理了，或者另一个库中的表数据同步一直不一致导致同步异常。
1）经报错信息查询该表数据统计记录master02的表数据量为：462740条。
2）同时也记录了master01数据库上，该表的数据量为：462733条。与master02对比发现数据量少了7条。
将master02上的这个表全表导出备份后，再将该表数据导入到master01中，最后还是报该表存在数据主键冲突，报错如下：
在导入过程中，需要关闭binlog的记录setsql_log_bin=0，避免导入数据表时报ID主键列冲突数据刷新到日志中，这样master01的表数据就会被master02的表数据全部置换，在主主同时写同时复制的情况下，之前一样的数据就没有了，最后剩下的是7条不一致的数据。虽然把主主复制功能恢复了，但是这个cer_work_order_temp表数据被新的二进制文件数据置换掉了，最终导致这表数据丢失。
通过全备+增量备份在测试环境对cer_work_order_temp表进行数据恢复，先找到增量起始点position812016541结合二进制日志进行恢复该表在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 |
删除原表主键，再重建新表及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; |
再把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 |
最终数据查询，如下查询已经恢复到原始数据量。
最后把这个表数据mysqldump到master01/master02数据库，再把双主复制功能恢复就可以了。
此次故障恢复还是算流畅的，没有遇到较大的难点，数据库服务器恢复正常后，也通知业务侧那边进行数据校验，同时得到他们的认可数据恢复一致，没有问题再现。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130108.html
摘要：上个文章集群搭建主主从模式中我们知道如何搭建主主从模式，今天这个文章正式进入高可用的架构。由开发，用来管理和监控双主复制，虽然是双主架构，但是业务上同一时间只允许一个节点进行写入操作。包含两类角色和分别对应读写节点和只读节点。 上个文章 MySQL集群搭建(2)-主主从模式 中我们知道如何搭建 MySQL 主主从模式，今天这个文章正式进入 MySQL 高可用的架构。 1 MMM 介绍 ...
MySQL高可用方案测试 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin...
阅读 1249·2023-01-11 13:20
阅读 1557·2023-01-11 13:20
阅读 1011·2023-01-11 13:20
阅读 1680·2023-01-11 13:20
阅读 3971·2023-01-11 13:20
阅读 2519·2023-01-11 13:20
阅读 1310·2023-01-11 13:20
阅读 3486·2023-01-11 13:20
