香港VPS MySQL主从复制故障恢复实战案例

在香港VPS搭建的MySQL主从复制环境中，数据同步突然中断是常见却棘手的问题。就像小朋友玩"传悄悄话"游戏时，传递消息的人突然停步、听消息的人也不吭声，整个同步流程卡壳——这种场景下该如何快速定位并解决故障？本文通过真实案例拆解恢复全流程。

故障现象：从机数据"静止"的信号

某用户在香港VPS运行的MySQL主从环境中，发现从机数据不再更新，与主机差异逐渐扩大。登录从机执行`SHOW SLAVE STATUS\G`命令后，关键参数Slave_IO_Running（IO线程状态）和Slave_SQL_Running（SQL线程状态）均显示为No。这两个指标如同复制流程的"双引擎"，任一停止都会导致数据同步中断，当两者同时失效时，意味着主从通信和数据应用环节全面停滞。

诊断三方向：网络、配置与存储

要让"传悄悄话"游戏重新运转，需逐一排查三个核心环节：
1. 网络连通性：香港VPS与本地网络间的波动、防火墙规则（如3306端口未开放）可能阻断主从通信。可通过`ping 主机IP`测试连通性，用`telnet 主机IP 3306`验证MySQL端口是否可达。
2. 配置一致性：检查主从机`my.cnf`配置文件，若出现server_id重复（如主从均设为1），MySQL会因无法识别身份而拒绝复制；此外，二进制日志（binlog）格式、字符集等参数不一致也可能引发异常。
3. 磁盘空间：从机若因日志文件堆积或冗余数据占用导致磁盘空间不足（可用`df -h`查看），会直接影响SQL线程写入数据，就像"传信的小朋友"发现收件箱已满，只能暂停传递。

分步恢复：让复制流程重新跑起来

针对不同原因，可按以下步骤操作：
- 网络问题处理：确认防火墙开放3306端口（需联系香港VPS服务商调整安全组策略），若存在丢包或延迟过高，可尝试更换更稳定的网络线路。
- 配置修正：修改从机`my.cnf`中的server_id（建议设为唯一的4位数字），同步检查主从binlog格式（如统一为ROW模式），修改后执行`systemctl restart mysql`重启服务。
- 磁盘清理：通过`du -sh /*`定位大文件目录，删除过期日志（如`rm -f /var/lib/mysql/binlog.*`）或迁移备份数据，确保可用空间大于30%。

完成基础排查后，需手动重启主从复制：

STOP SLAVE;  -- 停止当前复制进程
CHANGE MASTER TO 
MASTER_HOST='主节点IP',
MASTER_USER='repl_user',  -- 复制专用账号
MASTER_PASSWORD='repl_pass',  -- 账号密码
MASTER_LOG_FILE='mysql-bin.000001',  -- 主节点当前binlog文件名
MASTER_LOG_POS=154;  -- 主节点binlog起始位置（需在主节点执行SHOW MASTER STATUS获取）
START SLAVE;  -- 启动复制

最后再次执行`SHOW SLAVE STATUS\G`，观察Slave_IO_Running和Slave_SQL_Running是否均为Yes，且Seconds_Behind_Master（延迟时间）逐渐归零，即表示复制恢复正常。

在香港VPS环境中维护MySQL主从复制，除了掌握故障恢复技巧，日常也需定期检查网络状态、监控磁盘空间，并通过定时备份（如使用`mysqldump`）降低数据丢失风险。遇到问题时保持耐心，从现象反推原因，多数故障都能快速解决。