主从复制单向同步、从库只读，双主复制双向同步、两端均可写；前者延迟明显但运维简单，后者易现冲突且脑裂恢复困难，适用场景取决于读写比例、一致性要求与运维能力。
主从复制和双主复制是 MySQL 最常见的两种高可用架构，核心区别在于写入能力分布、数据流向方向、冲突处理机制和运维复杂度。选错架构容易带来延迟、脑裂或写入失败等问题，不能只看“能不能用”，得看业务怎么写、读多还是写多、容错要求有多高。
主从复制是单向的：所有写操作必须发给唯一主库（Master），它把变更写进 binlog，再由从库（Slave）拉取并重放。从库只读，不可写。
双主复制是双向的：两台服务器互为对方的主和从，各自都能接受写请求，并把本机的 binlog 同步给对方。相当于两个 Master 在互相复制。
这意味着：
auto_increment_offset 和 auto_increment_increment 避免自增 ID 冲突（比如 A 用奇数、B 用偶数）主从复制天然存在同步延迟，尤其在大事务、网络抖动或从库性能不足时，从库可能落后几秒甚至几分钟。这对强一致性场景（如订单支付后立刻查状态）是个风险点。
双主复制同样有延迟，但问题更隐蔽：如果两个节点几乎同时修改同一行，且没做应用层协调，就会出现“后写覆盖前写”或主键冲突报错。MySQL 自身不自动合并冲突，靠 DBA 或中间件兜底。
常见缓解方式包括：
主从复制适合：
– 读远多于写的系统（如内容展示、报表查询）
– 允许短时延迟的备份/分析/灾备从库
– 架构简单、团队运维经验有限的中小业务
双主复制适合：
– 多地域部署，需要本地低延迟写入（如华东写华东库、华南写华南库）
– 对写可用性要求极高，不能容忍主库单点宕机超过秒级（配合 VIP 或 DNS 切换）
– 已有成熟冲突规避策略，或业务本身写操作天然隔离（如按用户 ID 分片写入不同库）
主从架构故障恢复相对可控：主库挂了，选一个延迟最小的从库提升为主，重配其他从库指向新主即可。工具如 MHA、Orchestrator 可自动化完成。
双主架构一旦发生脑裂（网络分区导致两边都以为对方宕机而继续写入），恢复极难：必须人工比对 binlog、合并数据、修复不一致，稍有不慎就丢数据。日常还需监控：
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
244
收藏
