MySQL原生不支持多主复制，因单向复制易致冲突；伪环形复制不可靠；可靠方案为MGR多主模式（需主键、ROW格式等严格条件）、ProxySQL分片或Galera同步集群。
MySQL 多主复制不是原生支持的模式
MySQL 官方版本（包括 8.0）不提供开箱即用的「多主复制」能力。所谓“多主”，通常指多个节点均可写入、且变更自动同步到其他节点——这在 MySQL 单实例 + 原生复制架构下无法安全实现。主从复制（CHANGE REPLICATION SOURCE TO）本质是单向、线性日志应用，双向或多向配置会直接导致 duplicate entry、GTID conflict 或数据覆盖丢失。
常见伪多主方案：环形复制（Ring Replication）及其致命缺陷
有人通过手动配置 A→B→C→A 的环形链路模拟多主，但该方式在生产中极不可靠：
-
auto_increment_offset和auto_increment_increment必须严格配对，稍有错位就会插入失败 - 任意节点宕机或延迟，整个环断裂，复制线程全部
STOPPED，且恢复后容易跳过事务或重复执行 - DDL 操作（如
ALTER TABLE）在不同节点执行时间不同，极易引发ERROR 1050 (42S01)或元数据不一致 - 无冲突检测与自动解决机制，两个节点同时更新同一行主键/唯一键，必有一方被静默丢弃或报错中断
真正可用的替代方案：基于 MGR 或第三方中间件
若业务确实需要多点写入能力，必须放弃原生复制，转向以下两类方案：
-
MySQL Group Replication（MGR）：官方提供的高可用插件，支持单主（默认）和多主模式（
group_replication_single_primary_mode=OFF）。但多主模式下要求所有表带主键、禁用SAVEPOINT、事务需短小，且写冲突时后提交者直接报ER_GR_HOLD_WAIT_TIMEOUT -
Proxy 层协调方案：如
ProxySQL+ 多个独立主从集群，由 Proxy 控制读写分离与分片路由；或使用Vitess实现逻辑多主分片。这类方案不依赖 MySQL 内部复制一致性，而是靠上层控制写入拓扑 -
外部共识系统：如
Galera Cluster（Percona XtraDB Cluster / MariaDB Galera），基于 wsrep API 实现同步复制和冲突检测，但其底层已非 MySQL 原生复制协议，部署和调优复杂度显著上升
配置 MGR 多主前必须确认的三件事
即使选择 MGR，开启多主也不是改一个参数就能跑起来：
- 所有节点的
server_id、gtid_mode=ON、enforce_gtid_consistency=ON、binlog_format=ROW必须完全一致且提前启用（否则无法加入组） - 每个节点的
group_replication_group_name必须是相同 UUID 字符串（如'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'），且不能与其他组重名 - 首次启动多主组时，必须确保所有节点数据完全一致（推荐从同一份备份恢复），否则加入过程会因
Group replication join failed with error: 3092被拒绝
多主真正的难点不在配置命令，而在于业务能否接受强一致性约束下的写入收敛行为——比如自增 ID 不连续、事务冲突回滚、写入吞吐随节点数增加反而下降。这些不是配置能绕开的，是分布式共识的固有代价。
