17370845950

MySQL主从默认异步复制，主库写入binlog后立即返回，延迟可达秒级至分钟级；半同步需安装插件并启用，至少一从库写入relay log后才确认；真正同步需MGR等分布式架构。

异步复制是 MySQL 主从的默认行为，不用额外配置

MySQL 5.5 之后的主从复制默认就是异步的：主库写入 binlog 后立即返回成功，不等从库 IO_THREAD 拉取或 SQL_THREAD 执行。这意味着高并发写入下主从延迟可能达秒级甚至分钟级，但吞吐量最高、对主库性能影响最小。

如果你没动过 sync_binlog、innodb_flush_log_at_trx_commit 或启用半同步插件，那当前就是纯异步模式——不需要任何配置动作就能跑起来。

• sync_binlog = 0（默认）：binlog 写入由 OS 缓存决定，崩溃可能丢 binlog
• innodb_flush_log_at_trx_commit = 1（推荐）：保证事务持久性，但会拖慢主库写入
• 从库延迟监控看 Seconds_Behind_Master，值 > 0 就说明正在异步追赶

半同步复制（semi-sync）是唯一开箱即用的“类同步”方案

MySQL 官方插件 rpl_semi_sync_master 和 rpl_semi_sync_slave 提供的是“至少一个从库收到并写入 relay log 后才返回成功”，不是真正同步（不等执行），但能显著降低数据丢失风险。它不要求所有从库响应，也不阻塞主库太久（超时后自动降级为异步）。

启用前需确认插件已安装，并在主从两端分别设置：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

• 必须在主库 my.cnf 中加 rpl_semi_sync_master_enabled=1，否则重启失效
• 从库启用后需执行 STOP SLAVE; START SLAVE; 才能注册为半同步候选节点
• 超时参数 rpl_semi_sync_master_timeout 默认 10000ms（10 秒），超时即退化为异步，避免主库卡死
• 查看状态用 SHOW STATUS LIK

  

  E 'Rpl_semi_sync%';，重点关注 Rpl_semi_sync_master_status 和 Rpl_semi_sync_master_yes_tx

真正同步复制（如 Group Replication）需要彻底换架构

MySQL 原生不支持多节点强一致同步复制。所谓“同步”，只有 Group Replication（MGR）通过 Paxos 协议实现多数派写入确认，但它不是传统主从模型，而是多写（或单写）的分布式集群。一旦启用 MGR，你就不能再用 CHANGE MASTER TO 那套主从语句了。

• MGR 要求所有节点开启 binlog、gtid_mode=ON、enforce_gtid_consistency=ON
• 启动时需配置 group_replication_group_name、group_replication_local_address 等 10+ 项参数
• 写入延迟明显高于半同步，且只支持 InnoDB 表、不兼容 MyISAM 或部分 DDL
• 网络分区时可能触发 auto-evict，节点被踢出集群，需人工干预恢复

选型关键不在“同步/异步”字面，而在 RPO 和 RTO 要求

业务是否允许主库宕机后丢失最后几秒事务？能否接受从库延迟 30 秒以上做故障切换？这两个问题的答案，比技术名词更重要。

• 日志类、分析类从库：异步足够，甚至可关 relay_log_recovery 加速启动
• 核心交易读写分离：半同步 + sync_binlog=1 + innodb_flush_log_at_trx_commit=1 是性价比最高的组合
• 金融级零容忍丢失：别只盯 MySQL 复制，得结合应用层双写、binlog 解析投递到 Kafka、异地多活等方案

配置再“同步”，只要没做跨机房部署或未验证脑裂处理逻辑，故障时照样丢数据。真正难的从来不是改几个参数，而是厘清数据链路里哪一环承担最终一致性责任。