MySQL 8.0 启动 MGR 前必须设 binlog_checksum = NONE，否则因校验不一致导致 START GROUP_REPLICATION 卡住；group_replication_group_seeds 必须用 host 名（非 IP），且需 /etc/hosts 互相解析；bootstrap 仅限首个节点执行一次；单主模式下写操作必须发往实时 PRIMARY 节点，需每次查询 performance_schema.replication_group_members 确认。
MySQL 8.0 启动前必须关掉 binlog_checksum
很多人在 START GROUP_REPLICATION 时卡住，日志里反复报 Plugin group_replication reported: 'The member's configuration does not match the group's configuration'，根本原因是没关 binlog_checksum。MGR 要求所有节点的 binlog 校验方式完全一致，而 MySQL 8.0 默认开启 binlog_checksum = CRC32，但 Group Replication 插件只支持 NONE。
必须在每个节点的 my.cnf 的 [mysqld] 段里显式写：
binlog_checksum = NONE
漏掉这行，哪怕其他所有配置都对，group_replication 插件也起不来——它会在启动时校验全局变量一致性，不匹配就拒绝加入组。
group_replication_group_seeds 必须包含所有节点的 local_address 格式
常见错误是把 group_replication_group_seeds 配成 "192.168.10.11:33061,192.168.10.12:33061"，结果第三个节点加不进去。MGR 内部用的是 host:port 形式做地址解析，不是 IP:port；它会尝试反向 DNS 查这个 host 名，查不到就直接失败。
正确做法是：
- 确保三台机器的
/etc/hosts互相映射：比如mgr-node1→192.168.10.11，mgr-node2→192.168.10.12，mgr-node3→192.168.10.13 -
group_replication_local_address和group_replication_group_seeds全部用 host 名：例如mgr-node1:33061、"mgr-node1:33061,mgr-node2:33061,mgr-node3:33061" - 不要混用 IP 和 host 名，哪怕看起来能 ping 通也不行
第一次启动必须只在一个节点上执行 bootstrap
group_replication_bootstrap_group = ON 只能设在第一个节点（比如 mgr-node1），且仅执行一次。如果误在多个节点都设为 ON 并启动，会出现两个独立的组，后续谁都连不上谁。
实操顺序严格如下：
- 先停掉所有节点的 MySQL
- 只在
mgr-node1的my.cnf里设group_replication_bootstrap_group = ON，其余节点保持OFF - 启动
mgr-node1，连接后执行：START GROUP_REPLICATION - 确认状态：
SELECT * FROM performance_schema.replication_group_members;应看到MEMBER_STATE = ONLINE且只有自己一行 - 再依次启动
mgr-node2和mgr-node3（它们的group_replication_bootstrap_group = OFF），各自执行START GROUP_REPLICATION
多节点同时 bootstrap 是 MGR 最典型的脑裂诱因，没有例外。
单主模式下写操作必须发给 PRIMARY 节点
MGR 单主模式不会自动路由写请求。应用层如果轮询三个节点发 INSERT，非 PRIMARY 节点会直接报错：ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement。
判断当前 PRIMARY 的方式只有这一种：
SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members WHERE MEMBER_ROLE = 'PRIMARY';
不能依赖 SELECT @@server_id 或主机名猜测；也不能靠心跳或延迟判断。MGR 的 PRIMARY 是动态选举出来的，可能因故障切换，必须每次写前查一次，或者用 MySQL Router 做透明代理——否则应用一定会出错。
真正容易被忽略的是：即使你手动确认过某节点是 PRIMARY，只要它在你发写请求前发生了故障转移，你的请求仍会失败。生产环境不配 Router 或中间件的话，应用必须实现重试 + 角色重探逻辑。
