1. 线上环境排错前的准备与信息收集
本篇聚焦的核心场景是 MySQL 升级后出现的主从复制异常，围绕“线上环境排错与修复全流程”展开，确保在生产环境中的可控性与数据安全性。 在开始排错前，先明确当前影响范围、影响的数据库对象和业务时间线，避免在修复过程中引入新的问题。
备份与风控是排错的第一步，任何操作都应确保可回滚。 常见做法包括对主库和从库做实时或快照级别的备份，并记录在案以便对比与回滚。
# 在不干扰业务的前提下，获取全量备份并记录二进制日志位置
mysqldump --all-databases --flush-logs --master-data=2 > backup.sql
# 如果有二进制日志切换，记下当前主库状态，便于对账
信息收集的关键点在于掌握当前复制状态与配置基础。 需要收集的核心信息包括主从状态、Binlog 设置、GTID 配置、以及最近一次升级的版本差异。
SHOW MASTER STATUS\G
SHOW SLAVE STATUS\G
SELECT @@GLOBAL.version, @@GLOBAL.gt_id_strict_mode;
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'server_id';
记录日志路径与错误边界也非常重要。 关注 MySQL error log、relay log、以及操作系统层面的 I/O 状况，以便区分是数据库内部问题还是外部环境引起的抖动。
2. 现象定位与初步诊断
通过对比主从状态，可以快速初步判断复制的方向性问题。 关注 Slave_IO_Running、Slave_SQL_Running、Last_IO_Errno、Last_SQL_Errno 等字段的取值与错误信息。
常见的初步诊断要点包括：IO 线程是否工作、SQL 线程是否停滞、错误日志中是否有 binlog 相关异常。 下面的命令用于快速核对现状。
SHOW SLAVE STATUS\G
SHOW MASTER STATUS\G
在排错过程中，错误信息往往指向具体的异常点：如 GTID 不一致、Binlog 格式冲突、网络延迟或权限变更。 将这些信息与升级后的变更点对照，是快速定位的关键。
3. 排错路径：常见原因与定位要点
3.1 版本/兼容性导致的问题
升级后的新版本特性或行为差异，可能影响 GTID、日志格式或重放逻辑。 先检查 GTID 相关状态与日志格式的兼容性。
要点包括：GTID 状态、GTID_PURGED、GTID_EXECUTED 的一致性，以及 binlog_format 的兼容性。
SELECT @@GLOBAL.gtid_purged, @@GLOBAL.gtid_executed;
SHOW VARIABLES LIKE 'gtid_mode';
SHOW VARIABLES LIKE 'binlog_format';
如果 GTID 不一致或升级后 GTID 相关参数发生改变，需对照数据库版本的 GTID 行为文档，决定是否需要重置或重新配置。
3.2 Binlog 格式与复制格式不一致
Binlog 格式不一致是常见的升级后原因，尤其在从 MYISAM/InnoDB 切换到不同的事务日志策略时。 一致性检查是排错的第一步。
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';
如发现不一致，需统一两端的 binlog_format，必要时在从库执行重同步操作。
3.3 IO/SQL 线程异常与网络/权限相关
IO 线程或 SQL 线程异常会直接导致复制中断，常见表现为 Slave_IO_Running=No、Slave_SQL_Running=Yes/No。 同时关注错误码和描述信息。
SHOW SLAVE STATUS\G
# 若 Last_IO_Errno 指向网络/权限问题，可结合系统日志排查
排错要点包括网络可达性、防火墙是否更改、用户权限是否被改动，以及是否有 SSL/TLS 配置变更。
3.4 数据不一致与跳变的无法回滚场景
当升级后导致数据不一致，且无法从现有从库简单追溯时，需对比主从数据，定位差异范围。 这一步通常需要结合数据校验与增量对比工具进行深度排错。
-- 可用的对比手段示例（视环境选择工具）
SELECT COUNT(*) FROM database.table WHERE checksum_hash <> (SELECT checksum_hash FROM database.table WHERE id = table.id
);
为了更高效对比，推荐使用工具进行表级或分区级校验，如 pt-table-checksum/pt-table-sync，但前提是先确认升级后两端的一致性策略。
4. 修复动作与落地执行
4.1 在低风险模式下的修复操作要点
执行修复前应确保业务最低影响，必要时切换到只读或短期限流状态。 先尝试重置从库状态或重新指向主库的位点。
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS\G
RESET SLAVE ALL;
CHANGE MASTER TO MASTER_LOG_FILE='master-bin.000001', MASTER_LOG_POS=12345;
START SLAVE;
UNLOCK TABLES;
以上步骤适用于从库需要对齐主库位点的场景，确保双方日志位点一致。
4.2 GTID 模式下的修复要点
在 GTID 模式下，修复聚焦点是确保 GTID 集与主从一致，避免重复执行或丢失事务。 常见做法包括 RESET MASTER/RESET SLAVE ALL 及重新 CHANGE MASTER TO 指定 GTID，则可避免日志位置错乱。
RESET MASTER;
RESET SLAVE ALL;
CHANGE MASTER TO MASTER_PORT=3306, MASTER_HOST='master.example.com', MASTER_USER='repl', MASTER_PASSWORD='REPL_PASS', MASTER_AUTO_POSITION=1;
START SLAVE;
4.3 修复后的验证与持续保护
修复后应立即进行状态回归验证，确保 Slave_IO_Running 与 Slave_SQL_Running 为 Yes，且 Last_IO_Errno/Last_SQL_Errno 为 0。
SHOW SLAVE STATUS\G
另外，针对持续的生产环境，建议在复制链路上部署健康探针与告警，避免再度出现同类问题。
# 简化示例：监控复制延迟
mysql -e "SHOW SLAVE STATUS\G" | grep -E "Seconds_Behind_Master|Slave_IO_Running|Slave_SQL_Running"
5. 数据一致性最终校验与回滚策略
在完成修复动作后，进行数据一致性检查是最终保障措施，确保主从数据没有实际差异。 可以通过对比主从表的行数、校验和或使用专门的表级对比工具，确保没有未同步的变更。
pt-table-checksum D=database,t=table --no-check-plan
# 如发现不一致，进一步执行
pt-table-sync h=master D=database,t=table P=1234 --execute
对线上系统而言，最关键的是在定位到异常点后实现可控的重放与数据对齐，并在完成验证后继续监控。
