MySQL主从复制报错排查实录：从‘server-id’到‘UUID相同’，我的完整排错日志

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_HOSTmaster_host, MASTER_USERrepl, MASTER_PASSWORDpassword, MASTER_AUTO_POSITION1; START SLAVE; -- 检查复制状态 SHOW SLAVE STATUS\G当看到Slave_IO_Running: Yes和Slave_SQL_Running: Yes时我知道这场破案行动终于圆满结束。晨光透过窗户照进来一杯咖啡下肚我开始在团队Wiki上记录这次排查的完整过程特别标注了多数据目录陷阱这个容易忽视的细节。