MySQL主库高峰期备份引发504故障：从库手动切换接管 + 主从恢复同步 + Docker版DB2重启实战_2026-05-17

生产环境一次典型故障处理记录。

现象很经典：

系统接口大量 504
业务无法正常写入

排查后发现：

• MySQL 主库正在执行 xtrabackup 热备

• 备份时间处于业务高峰期

• 数据库 IO 压力升高

• 接口请求超时

• 应用出现 504

同时还涉及：

• MySQL 从库临时切换为可写

• 主库恢复后重新恢复主从同步

• Docker 容器中的 DB2 数据库重启恢复

这篇文章只记录核心处理流程。

---

一、问题现象

服务器负载检查：

top

发现：

mysqld CPU 占用非常高
xtrabackup 正在运行
wa(IO等待)升高

进一步检查：

ps -ef | grep xtrabackup

发现备份任务：

xtrabackup --backup ...

查看 crontab：

crontab -l

发现：

40 17 * * * /home/mysql_backup/backup.sh

也就是：

每天 17:40 执行 MySQL 物理热备

而此时间段正处于业务高峰期。

---

二、停止 xtrabackup 备份任务

先停止备份进程：

kill xtrabackup_PID

检查是否结束：

ps -ef | grep xtrabackup

确认无进程即可。

随后删除未完成备份目录：

rm -rf /home/mysql_backup/2026-05-16_1740

---

三、MySQL 从库临时切换为可写

由于主库异常，需要临时将从库接管业务。

登录从库：

mysql -uroot -p

查看只读状态：

show variables like 'read_only';
show variables like 'super_read_only';

默认：

ON

停止主从复制：

stop slave;

关闭只读：

set global super_read_only=OFF;
set global read_only=OFF;

确认：

show variables like 'read_only';
show variables like 'super_read_only';

结果：

OFF

此时：

从库正式切换为可写库

业务随后切换连接至从库。

---

四、从库无法连接问题处理（3306 防火墙）

虽然 MySQL 已监听：

ss -lntp | grep 3306

但远程仍报：

2002 - Can't connect to server
10060

检查 firewalld：

firewall-cmd --list-all

发现：

3306 未放通

直接关闭防火墙：

systemctl stop firewalld
systemctl disable firewalld

随后从库恢复远程连接。

---

五、主库恢复正常后，重新切回只读并恢复同步

主库恢复后，需要把从库重新恢复为：

只读 + 主从同步

重新开启只读：

set global read_only=ON;
set global super_read_only=ON;

重新开启同步：

start slave;

检查同步状态：

show slave status\G

重点确认：

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

说明主从同步恢复正常。

---

六、Docker 容器中的 DB2 数据库重启

环境中的 DB2 为 Docker 部署。

查看容器：

docker ps

发现：

db-db2

通过 docker restart 重启 DB2 容器服务

重启 Docker 部署的 DB2 容器（db-db2）：

docker restart db-db2

注意：本次操作执行的是 docker restart db-db2，属于重启单个 DB2 容器，并不是重启 Docker 服务。如果执行 systemctl restart docker，则是重启 Docker 引擎，可能导致该服务器上的所有容器受到影响。

docker restart db-db2
= 重启某一个容器：db-db2

systemctl restart docker
= 重启 Docker 服务/ Docker 引擎

查看状态：

docker ps | grep db-db2

查看日志：

docker logs --tail=100 db-db2

关键日志：

SQL1063N DB2START processing was successful.

说明：

DB2 启动成功

---

七、故障总结

本次问题本质上是：

MySQL 热备任务在业务高峰执行
导致数据库 IO 压力升高
接口请求超时
最终触发 504

这类问题在生产环境非常常见。

后续优化建议：

• MySQL 备份改至凌晨低峰期

• 备份与压缩分离

• 避免高峰期执行 xtrabackup

• 主从切换前必须确认原主库停止写入

• Docker 数据库容器需保留快速重启方案

一句话总结：

数据库很多时候不是"挂了"，而是"被高峰期备份拖慢了"。