从master.info文件反推：一次线上主从故障排查教会我的Change Master要点
凌晨3点15分，监控系统突然发出刺耳的警报声——生产环境的MySQL从库同步中断了。作为值班运维工程师，我立刻登录服务器检查SHOW SLAVE STATUS的输出，发现Last_IO_Error显示"Could not find first log file name in binary log index file"。这种错误通常意味着主从日志坐标不匹配，但更棘手的是，主库的binlog已经被自动清理，无法直接通过常规方式修复。这时，我意识到必须深入底层，从master.info和relay-log.info这两个元数据文件中寻找线索。
1. 紧急诊断：解读master.info文件结构
当主从复制中断时，/var/lib/mysql/master.info文件保存着最原始的连接配置和复制状态。与SHOW SLAVE STATUS不同，这个文件直接反映了磁盘上的持久化数据，不会因服务重启而丢失。以下是当时我遇到的典型文件内容：
25 mysql-bin.000014 1818 192.168.1.11 repl 123456 3306 60 0 0 30.000 0 95cfc8eb-2d58-11ea-840b-000c296166d5 86400 0这个看似简单的文本文件实际上包含15行关键信息，每行对应特定的配置参数：
- 文件格式版本号（如25）：表示master.info的格式版本，不同MySQL版本可能不同
- 主库binlog文件名（mysql-bin.000014）：从库IO线程最后读取的主库日志文件
- 主库binlog位置（1818）：从库IO线程最后读取的主库日志位置
- 主库IP地址（192.168.1.11）
- 复制账号用户名（repl）
- 复制账号密码（123456）：以明文存储，需注意权限安全
- 主库端口号（3306）
- 连接重试间隔（60秒）
- SSL连接标识（0表示禁用）
- SSL验证标识（0表示不验证）
- 心跳间隔（30.000秒）
- 绑定网卡标识（0表示未指定）
- 主库UUID（95cfc8eb-2d58-11ea-840b-000c296166d5）
- 重试次数限制（86400）
- 主库服务器ID（0表示未设置）
注意：从MySQL 5.6开始，master.info文件格式增加了更多字段，建议对照官方文档确认具体版本的文件结构。
2. 关键参数逆向工程：从文件到CHANGE MASTER命令
通过分析master.info和relay-log.info，我们可以重建完整的CHANGE MASTER命令。以下是核心参数的映射关系：
| 文件位置 | 对应参数 | 示例值 | 是否必选 |
|---|---|---|---|
| 第2行 | MASTER_LOG_FILE | mysql-bin.000014 | 非GTID模式必选 |
| 第3行 | MASTER_LOG_POS | 1818 | 非GTID模式必选 |
| 第4行 | MASTER_HOST | 192.168.1.11 | 必选 |
| 第5行 | MASTER_USER | repl | 必选 |
| 第6行 | MASTER_PASSWORD | 123456 | 必选 |
| 第7行 | MASTER_PORT | 3306 | 可选（默认3306） |
| 第8行 | MASTER_CONNECT_RETRY | 60 | 可选（默认60） |
| 第14行 | MASTER_RETRY_COUNT | 86400 | 可选 |
在本次故障中，我发现master.info中记录的binlog文件(mysql-bin.000014)已被主库轮转删除。此时需要结合relay-log.info确定从库的执行进度：
$ cat /var/lib/mysql/relay-log.info 7 ./mysql-relay-log.000002 1539 mysql-bin.000014 1818 0 0 1这个文件显示从库SQL线程已执行到relay-log.000002的1539位置，对应主库的mysql-bin.000014的1818位置。基于这些信息，重建CHANGE MASTER命令的关键步骤如下：
在主库上确认当前活跃的binlog文件：
SHOW MASTER STATUS;如果旧binlog已不存在，需要从最新文件开始同步：
CHANGE MASTER TO MASTER_HOST='192.168.1.11', MASTER_USER='repl', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000015', -- 使用主库当前文件 MASTER_LOG_POS=4; -- 从文件开头开始对于数据一致性要求高的场景，建议先使用
pt-table-checksum校验数据差异
3. 高级故障场景处理策略
3.1 主库IP变更但未更新master.info
当主库服务器迁移导致IP变更时，master.info中的旧IP会导致复制中断。此时需要：
停止从库复制：
STOP SLAVE;仅更新主机参数：
CHANGE MASTER TO MASTER_HOST='新IP';重启复制：
START SLAVE;
重要：修改MASTER_HOST会导致从库认为连接的是新主库，即使IP实际相同。此时必须重新指定MASTER_LOG_FILE/MASTER_LOG_POS或启用GTID。
3.2 密码轮换导致认证失败
当复制账号密码修改后，只需更新MASTER_PASSWORD而无需重置整个复制链路：
STOP SLAVE; CHANGE MASTER TO MASTER_PASSWORD='新密码'; START SLAVE;3.3 主库启用SSL连接
如果主库突然启用SSL连接，需要添加以下参数：
CHANGE MASTER TO MASTER_SSL=1, MASTER_SSL_CA='/path/to/ca.pem', MASTER_SSL_CERT='/path/to/client-cert.pem', MASTER_SSL_KEY='/path/to/client-key.pem';4. 最佳实践与自动化运维建议
4.1 安全加固措施
由于master.info包含明文密码，必须严格限制文件权限：
chown mysql:mysql /var/lib/mysql/master.info chmod 600 /var/lib/mysql/master.info4.2 关键参数检查清单
定期验证以下参数是否与运行环境匹配：
- 主库网络可达性（MASTER_HOST:MASTER_PORT）
- 复制账号权限（MASTER_USER/MASTER_PASSWORD）
- 日志坐标一致性（MASTER_LOG_FILE/MASTER_LOG_POS）
- 重试策略（MASTER_CONNECT_RETRY/MASTER_RETRY_COUNT）
4.3 自动化监控脚本示例
以下Bash脚本可实时检测复制状态并解析master.info：
#!/bin/bash # 检查复制状态 SLAVE_STATUS=$(mysql -e "SHOW SLAVE STATUS\G") # 解析master.info MASTER_INFO=$(cat /var/lib/mysql/master.info | sed -n '2,4p') LOG_FILE=$(echo "$MASTER_INFO" | sed -n '1p') LOG_POS=$(echo "$MASTER_INFO" | sed -n '2p') MASTER_HOST=$(echo "$MASTER_INFO" | sed -n '3p') # 输出关键指标 echo "当前主库: $MASTER_HOST" echo "最后成功读取的日志: $LOG_FILE @ $LOG_POS" echo "复制错误: $(echo "$SLAVE_STATUS" | grep "Last_Error" | cut -d: -f2-)"那次凌晨的故障最终通过分析master.info中的历史日志坐标，结合主库备份的binlog索引文件，成功重建了复制链路。这个过程让我深刻体会到，真正的运维专家不仅要会执行标准的CHANGE MASTER命令，更要理解其背后的数据持久化机制。现在，我会定期备份master.info和relay-log.info文件，特别是在执行任何复制配置变更之前——这些看似简单的文本文件，关键时刻就是救命的稻草。
