MySQL组复制启动主节点时自动开启super_read_only问题排查

现象的本质逻辑 #

这是组复制的内置安全机制，不属于异常报错：

• 组复制插件在启动初始化阶段，会第一时间把实例强制设为super_read_only=ON，避免实例在完成组内成员认证、角色选举流程前，接收外部写请求造成数据一致性问题
• 当实例成功完成全流程判定后，会自动调整只读状态：单主模式下选举产生的主节点会自动关闭super_read_only，所有从节点会保持super_read_only=ON
• 你当前一直停留在Setting super_read_only=ON日志位置，本质是主节点没有完成完整的组引导、角色判定流程，所以无法从前置的只读安全状态退出

现有配置与执行流程的核心遗漏 #

• 引导顺序颠倒：你的存储过程中先创建用户、配置复制通道，再设置group_replication_bootstrap_group=1，最后才启动组复制。正确引导逻辑必须先将实例设置为引导模式，再触发组复制启动，前置的非组复制操作会干扰引导初始化流程
• 复制通道配置无效：你给group_replication_recovery通道配置的认证用户是root，既没有对应密码配置，也没有把提前创建的repl用户配置到通道中，甚至repl用户本身没有设置密码、没有授予组复制必需的REPLICATION SLAVE、CLONE_ADMIN等权限
• Docker网络参数漏配：你只配置了group_replication_group_seeds，没有为每个实例显式配置group_replication_local_address。容器环境下组复制默认取实例主机名+3306作为组通信地址，和固定的组通信端口33061不匹配，主节点引导后无法完成自身的通信握手，卡在初始化阶段
• 引导参数残留风险：你设置group_replication_bootstrap_group=ON后，如果组复制启动失败，该参数会持续生效，后续无论怎么重启都会触发重复引导，造成脑裂
• 存储过程调用不匹配：你创建的存储过程名为set_as_master，但实际调用的语句是CALL start_as_master;，二者名称不匹配会导致执行中断，你看到的日志为上一次启动残留的状态

修正后的操作步骤 #

• 先重置残留状态：执行STOP GROUP_REPLICATION;，将全局参数group_replication_bootstrap_group手动改回OFF，清理上次启动的残留配置
• 补全my.cnf的网络配置：为每个实例添加对应配置，确保容器间33061端口双向互通：
  loose_group_replication_local_address = 对应容器主机名:33061
• 修正复制权限与通道配置：
  1. 创建带固定密码的复制用户，授予REPLICATION SLAVE, BACKUP_ADMIN, CLONE_ADMIN权限
  2. 将该用户配置到组复制恢复通道：

     CHANGE MASTER TO 
       MASTER_USER='repl', 
       MASTER_PASSWORD='设置的复制用户密码' 
       FOR CHANNEL 'group_replication_recovery';
     

• 调整主节点引导的存储过程逻辑：
  1. 启动前检查并确认super_read_only为OFF、group_replication_bootstrap_group为OFF
  2. 先执行SET GLOBAL group_replication_bootstrap_group=ON;
  3. 再执行START GROUP_REPLICATION;
  4. 确认启动成功后，立刻将group_replication_bootstrap_group重置为OFF，避免参数残留
• 启动完成后查询performance_schema.replication_group_members，当主节点的member_role字段显示为PRIMARY时，插件会自动关闭super_read_only，退出只读状态

内容的提问来源于stack exchange，提问作者Aren Hovsepyan