记录一次MySQL主从同步故障，后续重建过程。_记录一次mysql主从同步故障,后续重建过程

项目场景：

 项目上面数据库架构是两主两从的架构配置，KEEPALIVED配置在两台主库上面，每隔三分钟通过脚本检测一次数据库存活状态，当数据库无法读操作时，KEEPALIVED进行地址漂移。

 后端应用读取的时候是读取的从库的数据，写入是往主库写数据后续进行从库同步。应用主机通过ProSQL进行链接数据库。

---

问题描述

    上午出去玩的时候收到一封告警邮件，说主库的地址漂移了，因为知道架构时两主的配置嘛，一开始就没有那么着急登上去查看，大概过了几分钟后业务告警也随之而来，然后就慌的一批。

---

原因分析：

    从库到达最大链接之后，读/写请求分配至主库，主库到达最大连接（Too many connections）后keepalived地址消失，无法自动配置在主机虚拟网卡上，故页面访问异常。后授权资源池重启过后，主从库I/O线程同步异常，Proxysql读取数据库处于SHUNNED（下线状态），所有读/写请求由主库承担，故访问延迟高。通过恢复从库，负载分流后，业务恢复正常。

      运维千万不要上头！！！！冷静分析！！！！！千万不要梭哈服务器！！！！！！

---

解决方案：

 登上主机后查看keepalived的日志信息，发现检测到数据库异常了，但是没有漂移走

 然后尝试手动启动KEEPALIVED，发现怎么也起不来，有点恼火，怀疑是数据库是不是又抽风了，然后登上数据库查看，读写操作都可以，最后查看数据库主从配置，挂了。。。

 最后定位到是到达最大连接后，一直再这占着茅坑不拉屎，没办法处理请求了

 然后想方设法的恢复主库，把所有应用的链接都断掉、DB重启都没办法释放链接，因为影响到业务很久很久了，一气之下直接梭哈，重启服务器。。。。。。

芭比Q了，重启完之后主从怎么也起不来了，这报错见都没见过，指定BINLOG文件位置、set日志等其他办法都用了一个遍，报错依旧

 最后经过开会讨论，其他DBA大牛远程协助，得出了最终结论，重建主从吧。。。。我滴妈，2.7T的库重建三台主从每一天搞不完阿。。没办法了只能重建了

---

---

重建步骤如下：

我们这边采用xtrabackup的方式进行导入导出，另外三台数据库安装NFS，主库挂在直接备份到从库了，传输速度受网络，磁盘I/O影响。

数据库一台一台的导出导入肯定行不通了，只能通过压缩的方式备份了，但是这种方法压缩、解压又是一部分时间出去了，最终恢复了三十多个小时才搞定。

下面路径已实际路径为准！NFS的搭建过程就不再多多解释啦

在主库备份：

nohop xtrabackup --defaults-file=/etc/my.cnf  --user=XXXX --password='XXXXXXX' --backup --target-dir=/mysql_backup --skip-tables-compatibility-check --parallel=16 > 20230528_bak.log --compress &

在需要恢复的主机操作：

解压

xtrabackup --defaults-file=/etc/my.cnf --decompress --remove-original --parallel=20 --use-memory=30G --target-dir=/data/backup

准备数据：

xtrabackup --defaults-file=/etc/my.cnf --prepare --parallel=20 --use-memory=40G --target-dir=/data/backup

最后显示 如下信息，表示 恢复成功
Starting shutdown...
Log background threads are being closed...
Shutdown completed; log sequence number 31636301645334
220517 05:43:25 completed OK!

在新库删除数据

rm -rf /data/mysql/*

恢复数据：

xtrabackup --defaults-file=/etc/my.cnf  --use-memory=40G --parallel=20 --move-back --target-dir=/data/backup/

接下来操作

chown -R mysql:mysql /data/mysql
cd /data/mysql
systemctl start mysqld.service

SSL KEY文件重新全部生成

mysql_ssl_rsa_setup --datadir=/data/mysql

chmod 644 private_key.pem
chmod 644 server-key.pem

9、在备库配置主从复制：

#查看xtrabackup_binlog_info中记录的日志文件名+对应的位置
cd /data/backup
cat xtrabackup_binlog_info

mysql-bin.009071        2934 

mysql -uroot -p
-- master_log_file 对应上面 mysql-bin.009071,master_log_pos 对应上面的2934 
change master to master_host='主库IP地址',master_port=3306,master_user='XXX',master_log_file='mysql-bin.009071', master_log_pos=2934,master_password='XXXXXXX';

启动主从

start slave;

检查主从复制

show slave status\G;

如果数据库存在大量读写操作时，不要进行导出操作，因为数据库存在大量写操作，Innodb产出的日志速度大于Xtrabackup的备份的速度，部分Innodb日志被截断，导致备份失败。

最后登上主机，查看ProxySQL的状态，都恢复正常啦

PS：恢复期间各种问题：

1、xtrabackup提示版本有问题，xtraback版本一定要跟数据库版本对应起来，版本不对无法导出

2、提示 ALTER TABLE ALGORITHM=COPY 下面的这一堆挨个执行下 例：ALTER TABLE dccp_prod ALGORITHM=COPY。

期间存在各种坑，如果各位在恢复过程中出现问题欢迎私信我~~，有时间定会一一解答