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

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