MySQL主从复制故障排查实战：从server-id到UUID冲突的完整破案记录
那天凌晨两点，数据库监控突然发出刺耳的警报声。作为团队里负责MySQL高可用架构的运维工程师，我揉了揉酸胀的眼睛，盯着屏幕上不断闪烁的"Slave_SQL_Running: No"警告。这是一套刚部署不久的MySQL主从集群，白天业务高峰期即将到来，必须尽快恢复同步。接下来的六个小时，我像侦探破案般层层深入，最终解决了这个看似简单却暗藏玄机的复制故障。
1. 第一现场：基础配置排查
任何故障排查都应该从最简单的可能性开始。对于MySQL主从复制，server-id冲突是最常见的初级错误。我迅速登录从库服务器，检查了这个"犯罪嫌疑人"。
# 检查my.cnf配置文件路径 $ mysql --help | grep my.cnf order of preference, my.cnf, $MYSQL_TCP_PORT, /etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf在确认配置文件位置后，我对比了主从库的server-id设置：
# 主库/etc/my.cnf [mysqld] server-id = 1 log_bin = mysql-bin # 从库/etc/my.cnf [mysqld] server-id = 2 log_bin = mysql-bin看起来server-id配置正确，排除了这个最明显的嫌疑。但经验告诉我，配置文件修改后需要确认是否真正生效：
-- 在MySQL中验证实际生效的server-id SHOW VARIABLES LIKE 'server_id';当两个值都显示正确时，我知道需要转向下一个线索——错误日志。
2. 关键证据：错误日志分析
MySQL的错误日志就像犯罪现场的监控录像，记录着所有异常行为。根据my.cnf中的配置，我找到了日志文件位置：
# 查看错误日志路径 $ grep 'log-error' /etc/my.cnf log-error = /var/log/mysqld.log # 查看最新错误信息 $ tail -n 50 /var/log/mysqld.log日志中赫然显示着关键报错：
2023-06-15T02:17:23.735234Z 6 [ERROR] Slave I/O: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work. Error_code: 1593这个错误信息直指问题核心——主从库的UUID相同。但为什么会出现这种情况？我回忆起部署过程：为了快速搭建环境，我使用了VMware的虚拟机克隆功能创建了从库。克隆操作会复制包括MySQL数据目录在内的所有文件，自然也包括存储UUID的auto.cnf文件。
3. 深入调查：UUID冲突之谜
MySQL的server UUID是一个128位的唯一标识符，存储在数据目录的auto.cnf文件中。我首先确认了这个事实：
-- 查看当前生效的UUID SHOW VARIABLES LIKE 'server_uuid';果然，主从库显示完全相同的UUID值。按照常规解决方案，我需要修改或重新生成这个UUID：
# 查找auto.cnf文件位置 $ find / -name auto.cnf 2>/dev/null /var/lib/mysql/auto.cnf然而，当我按照标准流程修改这个文件后，问题却依然存在。这让我意识到，这个案件比表面看起来更复杂。
4. 隐藏陷阱：多数据目录的迷惑
在多次尝试修改/var/lib/mysql/auto.cnf无果后，我决定扩大搜索范围：
# 全盘搜索所有auto.cnf文件 $ sudo find / -name auto.cnf 2>/dev/null /var/lib/mysql/auto.cnf /opt/mysql/data/auto.cnf惊人的发现！系统里竟然存在两个auto.cnf文件。原来这套MySQL实例在部署时指定了自定义数据目录：
# 实际生效的配置片段 [mysqld] datadir = /opt/mysql/data而之前修改的/var/lib/mysql/auto.cnf根本不会被MySQL读取。这才是导致修改无效的真正原因！这种多数据目录的配置常见于以下场景：
- 使用非默认安装路径
- 多实例部署
- 历史遗留的配置迁移
5. 完美结案：彻底解决方案
锁定真正的auto.cnf文件后，我采用了最稳妥的解决方案：
# 停止MySQL服务 $ systemctl stop mysqld # 删除auto.cnf文件（MySQL启动时会自动生成新UUID） $ rm -f /opt/mysql/data/auto.cnf # 重启MySQL服务 $ systemctl start mysqld验证结果显示新的UUID已经生成：
SHOW VARIABLES LIKE 'server_uuid'; +---------------+--------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------+ | server_uuid | 6ccd603a-02e4-11ee-be56-0242ac120002 | +---------------+--------------------------------------+最后，重新配置复制链路并验证状态：
-- 在从库上执行 STOP SLAVE; CHANGE MASTER TO MASTER_HOST='master_host', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_AUTO_POSITION=1; START SLAVE; -- 检查复制状态 SHOW SLAVE STATUS\G当看到Slave_IO_Running: Yes和Slave_SQL_Running: Yes时，我知道这场"破案行动"终于圆满结束。晨光透过窗户照进来，一杯咖啡下肚，我开始在团队Wiki上记录这次排查的完整过程，特别标注了"多数据目录陷阱"这个容易忽视的细节。
