针对 MySQL ER_RPL_MTS_GROUP_RECOVERY_RELAY_LOG_INFO 报错，修复核心在于检查 Group Replication 配置与元数据一致性。首先需确认所有群组成员状态正常，检查 performance_schema 中的复制统计信息。若元数据丢失，需停止实例，重置 Group Replication 状态后重新启动。若问题持续，可能需要关闭所有成员，清理主库信息（RESET MASTER），并重新引导群组。远程处理时务必确保网络连通性及 server_id 唯一性，必要时跳过错误事务或重新同步数据以恢复集群正常运作，避免直接删除 relay log 文件导致位置丢失。

MySQL Error number: MY-010574; Symbol: ER_RPL_MTS_GROUP_RECOVERY_RELAY_LOG_INFO; SQLSTATE: HY000 报错 故障修复 远程处理 - 树叶云

MySQL Error number: MY-010574; Symbol: ER_RPL_MTS_GROUP_RECOVERY_RELAY_LOG_INFO; SQLSTATE: HY000 报错 故障修复 远程处理 文档解释 Error number: MY-010574; Symbol: ER_RPL_MTS_GROUP_RECOVERY_RELAY_LOG_INFO; SQLSTATE: HY000 Message: Slave: MTS group recovery relay log info group_master_log_name %s, event_master_log_pos %llu. MY-010574; ER_RPL_MTA_GROUP_RECOVERY_APPLIER_METADATA; HY000 错误是 MySQL 复制群中出现的，因为在 Group Recovery 的时候，Applier 的 metadata 未在其他 Group Replication 来源端检测到。常见案例 在 MySQL 群复制中，当 Group Replication 尝试执行 Group Recovery 时，可能会出现这个错误，原因是 Group Replication 未能在其他 Group Replication 来源端找到 Applier 的 metadata。这通常发生在某个 Group Replication 实例与群组崩溃或断裂期间，造成一些节点无法获得 Applier 元数据信息。解决方法 原因是，Group Replication 无法从配置的群组成员处检索 Applier 的元数据信息。确保以下步骤以及所有 Group Replication 成员定期在同一条线上运行：1. 检查 Group Replication 成员的状态:SELECT * FROM performance_schema.replication_group_member_stats; 2. 检查最新复制事件的状态:SELECT * FROM performance_schema.replication_applier_status_by_worker; 3. 检查服务器的地址表达式是否正确 (以确保所有的 Group Replication 成员都使用正确的地址):SELECT @@group_replication_group_seeds; 4. 停止实例，重置 Group Replication 状态，然后重新启动 Group Replication 如果这些步骤都没有帮到忙，可以重新部署整个 Group Replication 群组，使用下面的步骤，对所有 Group Replication 成员重新进行安装：1. 关闭所有 Group Replication 成员：SHUTDOWN ; 2. 清理所有 Group Replication 成员：RESET MASTER; 3. 在所有 Group Replication 成员上，重新安装 Group Replication: SET GLOBAL group_replication_bootstrap_group = ON; SET GLOBAL group_replication_start_on_boot = ON; START GROUP_REPLICATION; 4. 将 Group Replication 配置信息 (例如配置地址表达式) 应用于所有 Group Replication 成员 最后，检查 Group Replication 是否设置正确，以及所有成员是否加入群组：SELECT * FROM performance_schema.replication_group_members;（消息于 2025 年 5 月 24 日发布）

故障分析 | 浅谈 ERROR 1872 与 5.6/5.7 MTS group recovery

故障分析 | 浅谈 ERROR 1872 与 5.6/5.7 MTS group recovery 最近遇到一个在 MTS 环境下，ERROR 1872 Slave failed to initialize relay log info structure from the repository 的故障。本文将浅显分析在 MTS 环境下，该错误的成因，并简单聊一下 MTS crash safe 的因素。这个报错在 5.6 之前，或者单线程复制环境下也有可能出现，一般直接原因是仓库信息不对，如 relay log 目录不对，权限不对等问题造成，而此处讨论的 1872，为 MTS 环境下的 ERROR，注意区分。故障复现 背景和相关配置如下：结构：简单的 master -> slave 复制方式:auto_position=0 (file position based replication) 数据库版本:MySQL5.6.20 (5.6 的高版本应该也有这个问题) 关键配置：代码语言:javascript AI 代码解释 复现:(目前测下来，按以上参数设置，5.6 这个版本会 100% 复现)① 先按上条件和配置构做好复制，sysbench 给主库压力② kill -9 slave 节点的 mysqld 的 pid，等 mysqld_safe 自己拉起③ 观察 slave 节点 error log 的输出：代码语言:javascript AI 代码解释 [Note]Slave:MTSgroup recovery relay log info based on Worker-Id 7,group_relay_log_name $path/mysql-relay.000008,group_relay_log_pos 380015428group_master_log_name mysql-bin.000680,group_master_log_pos 380015258………… 可能有多个"MTSgroup recovery relay log info"信息 [Note]Slave:MTSgroup recovery relay log info group_master_log_name mysql-bin.000680,event_master_log_pos 380015258.[ERROR]--relay-log-recovery cannot be executed when the slave was stoppedwith an error or killed inMTSmode;consider using RESETSLAVEor restartthe server with--relay-log-recovery =0followed by STARTSLAVEUNTILSQL_AFTER_MTS_GAPS[ERROR]Failed to initialize the master info structure 看起来日志输出了 MTS 尝试从对应 relay log 恢复的日志输出，但这个时候，报错了 Failed to initialize the master info structure，虽 relay_log_recovery 打开了，但 MTS 场景并不是直接简单地重新拉取主库的 binlog。这里的【group】可以简单理解为事务，下面还会再提到。这个时候，SHOW SLAVE STATUS\G 的部分输出如下：代码语言:javascript AI 代码解释 看起来没有任何 ERROR 号，只是没启动双复制线程的样子，然而直接执行 START SLAVE; 就会报错 ERROR 1872 了（来自 2019 年 5 月 28 日的资料）

mysql 升级后无法启动报 Relay_log 错误怎么办_重置从库信息

mysql 升级后无法启动报 Relay_log 错误怎么办_重置从库信息 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 确认。（截至 2026 年 4 月 21 日）

FAQ

出现 ER_RPL_MTS_GROUP_RECOVERY_RELAY_LOG_INFO 错误的主要原因是什么？

主要原因是 Group Replication 无法从配置的群组成员处检索 Applier 的元数据信息，通常发生在实例与群组崩溃或断裂期间，造成一些节点无法获得 Applier 元数据信息。

修复该错误是否需要重启所有节点？

如果常规检查无效，可能需要关闭所有成员，清理状态后重新安装 Group Replication 并重启，具体步骤包括 SHUTDOWN、RESET MASTER 及重新配置启动参数。

如何检查 Group Replication 成员状态？

可以通过查询 performance_schema.replication_group_member_stats 表来检查成员状态，同时检查最新复制事件的状态及服务器地址表达式是否正确。