mysql升级后报er_rpl_recovery_error_read_relay_log，本质是元数据格式不匹配导致恢复失败；需确认repository为table、执行reset slave all、change master to原位点、start slave，并务必运行mysql_upgrade重建系统表。
MySQL升级后报 ER_RPL_RECOVERY_ERROR_READ_RELAY_LOG 或 Failed to open the relay log 怎么办
这不是 relay log 本身损坏的问题，而是升级过程触发了复制元数据校验逻辑失败——尤其常见于从库（slave）在 MySQL 5.7 升级到 8.0 后首次启动时。错误本质是 mysqld 尝试恢复 relay log 但找不到合法起点，或元数据存储格式不匹配。
为什么 relay_log_recovery=ON 没起作用
这个配置只在满足两个前提时才真正生效：
-
relay_log_info_repository和master_info_repository都必须设为TABLE（而非默认的FILE） - mysqld 必须完整重启（不是
SERVICE mysql reload），否则不触发 recovery 流程
升级前若用的是旧版文件存储模式（FILE），升级后即使配置了 relay_log_recovery=ON，启动时仍会因无法解析 relay-log.info 中的偏移而报错。查证命令：SHOW VARIABLES LIKE '%repository%';
安全重置从库元数据的实操步骤
不要直接删 relay-log.info 或 master.info 文件——这些文件在 TABLE 模式下已失效，删了反而导致位置丢失；也不要用 RESET SLAVE 后立刻 START SLAVE，那会从头拉 binlog，可能重复应用事件。
- 先停复制：
STOP SLAVE; - 确认当前已执行到的位置：
SHOW SLAVE STATUS\G，记下Exec_Master_Log_Pos和Master_Log_File - 清空元数据表（仅限
TABLE模式）：RESET SLAVE ALL;（注意是ALL，它会清空mysql.slave_master_info和mysql.slave_relay_log_info） - 重新指向原位置：
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;（用上一步记下的值） - 再启动：
START SLAVE;
如果仍报错 ER_SYNC_FAILED_TO_OPEN_RELAY_LOG，大概率是磁盘权限或 SELinux 拦截，检查 /var/lib/mysql/ 下 relay log 文件属主是否为 mysql:mysql，并运行 ausearch -m avc -ts recent | grep mysqld 确认。
升级后 relay log 相关配置要同步调整
MySQL 8.0 对复制路径和命名更敏感，旧配置容易引发主机名变更类问题：
- 避免依赖默认主机名生成 relay log：启动时加参数
--relay-log=relay-bin和--relay-log-index=relay-bin.index，或写入my.cnf的[mysqld]段 - 禁用已废弃变量：如
replicate-ignore-db在 8.0.23+ 被移除，保留会导致启动失败 - 检查
sql_mode：若含NO_AUTO_CREATE_USER，8.0 会拒绝启动，需删掉
最关键的遗漏点：很多人重置完就以为万事大吉，却忘了 mysql_upgrade 在 5.7→8.0 场景下仍是必需步骤——它会重建 mysql.slave_* 表结构。没跑这步，RESET SLAVE ALL 可能因表字段缺失而静默失败。
