记录一次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。

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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值