升级前必须锁定 binlog_format
并验证兼容性
MySQL 大版本升级（如 5.7 → 8.0）时，
binlog_format的默认值可能变更（例如 8.0 默认更倾向
ROW），而从库若仍用旧版 MySQL 解析新格式事件，容易报
Unknown binlog event type或解析失败。这不是 bug，而是官方明确的复制不兼容场景。 执行
SHOW VARIABLES LIKE 'binlog_format';确认主从当前值一致，升级前统一设为
ROW（推荐）或
MIXED，避免依赖默认行为 在
my.cnf中显式写死：
binlog-format = ROW，而非仅靠
SET GLOBAL临时设置（重启即失效） 查官方文档“Replication Compatibility”章节，确认目标版本是否支持你当前的 binlog 事件结构（例如 8.0.33+ 对
WriteRowsEvent v2支持更稳，旧从库可能不识别）
主从不能同时升级：必须滚动切换并校验位点
直接停主库、全量升级再拉起，会导致 binlog 断层——新主库生成的首个 binlog 文件（如
mysql-bin.000012）与原从库期望续接的文件（如
mysql-bin.000011）不连续，复制中断。 先升级一个从库：停服务 → 替换二进制 → 启动 → 执行
SHOW SLAVE STATUS\G，确认
Seconds_Behind_Master = 0且
Exec_Master_Log_Pos持续推进 记录原主库位点：
SHOW MASTER STATUS;输出的
File和
Position必须抄下来，这是后续人工对齐的唯一锚点 提升该从库为主后，原主库降级为从库时，需用
CHANGE MASTER TO ... MASTER_LOG_FILE='...', MASTER_LOG_POS=...精确指定起点，不能依赖
MASTER_AUTO_POSITION=1（GTID 在跨大版本时易出错）
binlog 文件迁移 ≠ 直接拷贝：路径、权限、索引三者缺一不可
把旧实例的
/var/lib/mysql/mysql-bin.*文件直接拷到新实例目录下，99% 会失败——MySQL 启动时会校验
mysql-bin.index内容与实际文件名是否匹配，且要求文件属主为
mysql用户、权限为
640。 若需复用历史 binlog（如审计、闪回），先在旧实例执行
FLUSH LOGS;确保当前日志已落盘，再用
cp+
chown mysql:mysql+
chmod 640三步操作 新实例的
my.cnf中
log-bin路径必须与拷贝目标路径一致；否则 MySQL 会忽略这些文件，自建新序列 启动后立刻执行
SHOW BINARY LOGS;，检查列表是否包含迁移来的文件名；若缺失，说明
index文件未更新或路径配置错位
升级后立即禁用自动清理，手动验证 binlog 连续性
MySQL 8.0.23+ 默认启用
binlog_expire_logs_auto_purge = ON，若升级后未及时检查，旧 binlog 可能被自动删掉，导致无法回溯升级前的操作。 升级完成首小时内，执行
SET GLOBAL binlog_expire_logs_auto_purge = OFF;暂停自动清理 用
mysqlbinlog --base64-output=decode-rows -v /path/to/mysql-bin.000011 | tail -20查看末尾事件，再对比新主库的
mysql-bin.000012开头是否有
Rotate事件指向前者，这是 binlog 连续的关键证据 确认无误后，再按需开启清理：
SET GLOBAL binlog_expire_logs_seconds = 604800;（7天）
真正麻烦的从来不是命令怎么敲，而是位点没记、格式没锁、index 没同步这三处——它们不会报错，但会让复制在某天凌晨突然卡住，且错误日志里只有一行模糊的
Could not parse relay log event entry。
