mysql主从复制和双主复制有什么区别_mysql架构对比

主从复制仅主库可写，双主复制两端均可写但需自行处理冲突；主从适用于读多写少、强一致性场景，双主适用于跨机房、最终一致性场景，但存在循环复制、ID冲突、延迟不可见等风险，运维复杂度远高于主从。主从复制只能写主库，双主复制两边都能写这是最根本的差异：主从架构下，INSERT/UPDATE/DELETE 必须发给唯一 master，从库（slave）设为只读（read_only=ON），强行写会报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。而双主是两个节点互为 master 和 slave，应用可向任意一端发起写请求------但这也意味着你必须自己兜底解决冲突。主从适合读多写少、强一致性要求高的场景（如订单中心），写路由集中，运维简单双主适合跨机房部署、需就近写入、且能接受最终一致性的业务（如日志采集、用户行为埋点）双主必须配 auto_increment_increment 和 auto_increment_offset，否则自增 ID 必撞（比如 A 设 offset=1, increment=2 → 用奇数；B 设 offset=2, increment=2 → 用偶数）双主复制天然存在循环写入和数据覆盖风险假设 M1 和 M2 是双主，M1 执行 UPDATE t SET balance = 150 WHERE id = 1，binlog 同步到 M2 并执行；M2 紧接着也执行了 UPDATE t SET balance = 130 WHERE id = 1，再同步回 M1 ------ 最终结果取决于谁后写、谁后同步，不是"谁先提交谁生效"。更危险的是，若没关掉 log_slave_updates 或没设对 server-id，一条语句可能在双主间无限循环复制（M1→M2→M1→M2...）。必须确保 server-id 全局唯一，且双主都开启 log_slave_updates=ON（否则无法接力同步）推荐使用 binlog_format=ROW，避免 STATEMENT 格式下函数（如 NOW()、UUID()）在两端产生不同结果禁止在双主上执行非确定性语句（如不带 WHERE 的 UPDATE、DELETE），否则极易导致数据不一致主从延迟是常态，双主"伪实时"但更难观测主从延迟（Seconds_Behind_Master）可直接查 SHOW SLAVE STATUS，几秒到几分钟都常见；而双主没有这个指标------你看到 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes，不代表数据已对齐。因为 M1 写完立刻返回成功，M2 可能还在重放中，此时若切流量过去，就可能读到旧值或空数据。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。