MySQL集群不直接支持自动多节点强一致同步，主流方案基于binlog异步/半同步复制；InnoDB Cluster通过Group Replication实现因果一致性与自动故障处理；双主/多源复制适用于特定场景但存在一致性风险。
MySQL 集群本身并不直接提供“集群内自动多节点强一致同步”的能力（如 PostgreSQL 的 Patroni 或 Redis Cluster 那样），常见所谓“MySQL 集群”实际多指基于主从复制（Replication）或高可用架构（如 MHA、Orchestrator、InnoDB Cluster / Group Replication）构建的多节点系统。数据同步的核心机制仍是 基于 binlog 的异步/半同步复制，不同方案在同步方式、一致性保障和故障切换逻辑上有所差异。
主从复制（Async/Semi-sync Replication）——最常用的数据同步基础
这是 MySQL 数据同步的底层基石：主库（Master）将数据变更写入二进制日志（binlog），从库（Slave）通过 I/O 线程拉取 binlog 并存为中继日志（relay log），再由 SQL 线程重放执行。
- 异步复制：主库提交事务后不等待从库确认，性能高但存在主库宕机导致部分事务丢失的风险（可能丢数据）。
- 半同步复制（需插件支持，如 rpl_semi_sync_master）：主库至少等待一个从库写入 relay log 并刷盘后才返回成功，兼顾一定可靠性与性能，是生产环境推荐的最低同步级别。
- 可通过
SHOW SLAVE STATUS\G查看Seconds_Behind_Master和复制线程状态，判断同步延迟与是否中断。
InnoDB Cluster（Group Replication + MySQL Shell）——面向最终一致的集群方案
MySQL 官方提供的集群方案，底层依赖 Group Replication（基于 Paxos 协议的插件）
，实现多主（可配置单主）模式下的冲突检测与自动仲裁。
- 所有节点都可读写（单主模式下仅主节点接受写入），写操作通过组通信协议广播，多数派节点确认后才提交，保证强一致性（严格讲是“因果一致性 + 写集认证”）。
- 自动处理节点故障：离线节点被踢出组，剩余节点继续服务；恢复后自动增量同步（使用 clone 插件或传统复制追平）。
- 要求表必须有主键，且只支持 InnoDB 引擎；网络延迟和带宽直接影响写入吞吐，不适合跨地域部署。
双主 / 多源复制（Dual-Master / Multi-Source）——特定场景下的补充同步
并非标准高可用集群，而是为解决特定需求设计的同步拓扑：
-
双主（Active-Active）：两台 MySQL 互为主从，各自接受写入。需严格规避主键冲突（如自增偏移
auto_increment_offset+auto_increment_increment）、避免同表同记录并发更新，运维复杂，一般不推荐用于核心业务。 - 多源复制：一个从库同时从多个主库拉取 binlog（MySQL 5.7+ 支持）。常用于数据归集、报表库建设，但各主库间无协调，无法保证跨库事务一致性。
同步可靠性与常见问题应对
无论哪种机制，同步都不是“开箱即用就绝对可靠”的，需主动监控与干预：
- 开启
sync_binlog=1和innodb_flush_log_at_trx_commit=1减少主库宕机丢事务风险；从库建议开启relay_log_recovery=ON防止崩溃后中继日志损坏。 - 定期校验主从数据一致性，可用
pt-table-checksum（Percona Toolkit）工具识别行级差异。 - 避免在从库执行写操作（除非明确设置
read_only=OFF且有充分理由），否则极易引发复制中断或数据错乱。 - 大事务、长事务、DDL 操作会显著拖慢 SQL 线程，造成延迟累积；建议拆分大事务，DDL 操作尽量在低峰期执行并配合 pt-online-schema-change 等工具。
