一、问题描述
两台服务器xx.96,xx.97
docker部署的haproxy+mycat+mysql
大概2023年某月，xx.97服务器宕机了，经过返厂维修，2-3个月后开机了，MySQL启动了，用户发现，写进去的数据读不到，读到的数据是几个月前的，没同步！负责运维的同事自己搞不定，打电话来求助。对他们一波发火，因为手上正在忙项目，凭自己对数据库高可用架构的猜测，决定把返修回来的那台，MySQL服务先关掉。等我有空了慢慢修复。因为，haproxy+mycat+mysql+keepalived双机高可用不是我设计的，也不是我部署的，虽然我大概知道这啥架构，都怎么配置的，配置文件都是哪个，参数是哪些。但是对环境完全不了解，让我短时间内修复，不干！
过了1个月后，我手上的项目结束了，主动安排这个事情，下面是维护过程的笔记，供想要的小伙伴参考：
0、修改了mycat的配置【两台都执行】：
<!--<writeHost host="hostS1" url="mysql2:3306" user="root"
password="密码" />--> #注释了这行
1、重启mycat
docker restart mycat1
docker restart mycat2
2、96上设置数据库只读
mysql> FLUSH TABLES WITH READ LOCK;
3、96上打印数据库日志位置
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| slave-bin.000068 | 19200684 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
4、备份96的数据库
/usr/bin/docker exec mysql-master sh -c 'exec mysqldump -uroot -p密码 --quick --all-databases --single-transaction' > /opt/szaisino/mysql/backup/backup_$(date "+%Y%m%d_%H%M%S").sql
5、96上恢复读写
#恢复读写之前，再次确认日志位置跟备份之前保持一致
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| slave-bin.000068 | 19200684 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
#执行解锁命令：
mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)
6、备份拷贝到97服务器
scp backup_20230802_105415.sql root@172.19.xx.97:/opt/szaisino/mysql/backup/
7、启动97上的mysql
docker start mysql-slave
8、97上用备份还原数据库
cd /opt/szaisino/mysql/backup
docker cp backup_20230802_105415.sql mysql-slave:/
docker exec -it mysql-slave bash
mysql -uroot -p密码 <backup_20230802_105415.sql
9、97上配置为96的从库
#清空原有的所有主从复制关系
reset slaeve all;
#执行新的主从配置命令
change master to
master_host='172.19.xx.96',
master_port=3306,
master_user='root',
master_password='密码',
master_log_file='slave-bin.000068',
master_log_pos=19200684;
10、验证主从复制状态
show slave status\G;
11、mycat的配置文件恢复原来的样子【主从服务器上都操作】并重启mycat
<writeHost host="hostS1" url="mysql2:3306" user="root"
password="密码" />
docker restart mycat1
docker restart mycat2
12、96取消主从复制配置
stop slave;
reset slave all;
#重新配置主从97到96
change master to
master_host='172.19.xx.97',
master_port=3306,
master_user='root',
master_password='密码',
master_log_file='master-bin.000126',
master_log_pos=95552338;
#上面的日志文件跟位置，在刚还原好97数据后就通过 在97上执行 show master status;记录了最早的一次。实际应该是通过其他方式找到更准确的同步位点，但是时间关系，环境是客户的，数据差异也估计不大，所以让运维自己去检查补充。
到此，双机上的主从复制都正常。然后回忆总结下：为什么97一启动，就优先拿到了主库的角色？决定检查所有的配置，且开始操作之前确认了/etc/hosts文件，发现有点奇怪,下下面的内容：
172.19.xx.97 mysql1 mycat1
172.19.xx.96 mysql2 mycat2
然而mycat是：
<writeHost host="hostM1" url="mysql1:3306" user="root"
password="密码">
</writeHost>
<writeHost host="hostS1" url="mysql2:3306" user="root"
password="密码" />
再看keepalived的配置：
96上是：
state BACKUP
interface eno1
virtual_router_id 25
priority 100 #192.168.1.193上改为120
97上是：
state MASTER
interface eno1
virtual_router_id 25
priority 120 #192.168.1.193上改为120
所以最终修改了mycat跟keepalived的配置
mycat改为：
<writeHost host="hostM1" url="mysql2:3306" user="root"
password="密码">
</writeHost>
<writeHost host="hostS1" url="mysql1:3306" user="root"
password="密码" />
96上keepalived改为：
state MASTER
interface eno1
virtual_router_id 25
priority 120 #192.168.1.193上改为120
97上keepalived改为：
state BACKUP
interface eno1
virtual_router_id 25
priority 100 #192.168.1.193上改为120
其中，mycat改完重启，keepalived没有重启，因为数据库双主同步已经正常，在机器不挂的条件下没必要重启keepalived，做了笔记，如果出现宕机，再重启也没问题。
