异步复制是 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 LIKE '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、异地多活等方案
配置再“同步”，只要没做跨机房部署或未验证脑裂处理逻辑，故障时照样丢数据。真正难的从来不是改几个参数，而是厘清数据链路里哪一环承担最终一致性责任。
