mysql 8.0双主架构本身不提供负载均衡，仅支持互为复制；读写分离必须依赖proxysql等中间件显式路由或vip高可用机制，直连轮询会导致写冲突、事务丢失和脑裂。
MySQL 8.0 的双主架构本身不提供负载均衡能力，它只是一对互为复制的节点；真正实现读写分离或请求分发，必须依赖外部中间件或 VIP 机制。直接让应用轮询两个 MySQL 实例，会引发写冲突、事务丢失、连接中断等严重问题。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
为什么不能把应用直连两个 MySQL 实例做“轮询负载”
常见错误是把 JDBC URL 写成 jdbc:mysql://192.168.10.101:3306,192.168.10.102:3306/db，期望驱动自动分发请求——这是危险的：
- MySQL Connector/J 的多地址模式仅用于故障转移（failover），不是负载均衡（load balance）
- 写操作仍会随机落到任一节点，若两节点同时写同一张表的自增主键，auto_increment_offset 配错就会主键冲突
- 事务跨节点无法保证原子性，START TRANSACTION 后执行 INSERT 再 COMMIT，可能只在其中一个节点生效
- 网络分区时极易脑裂，数据不一致后无法自动修复
必须配置的 MySQL 8.0 双主核心参数（两节点严格差异化）
双主不是“配两遍一样的 my.cnf”，关键参数必须错开，否则复制立即中断：
- server-id 必须全局唯一（如 1 和 2）
- auto_increment_increment = 2（两节点相同）
- auto_increment_offset 必须不同（节点1设为 1，节点2设为 2）
- gtid_mode = ON + enforce_gtid_consistency = ON（强烈推荐，避免位置复制错位）
- binlog-format = ROW（STATEMENT 模式在 NOW()、UUID() 等函数下必然导致从库数据偏差）
- log-bin 必须开启，路径可不同，但文件名建议统一为 mysql-bin
用 ProxySQL 实现真正的读写分离与负载均衡
ProxySQL 是目前最成熟、可控性强的 MySQL 中间件方案，它能识别 SQL 类型并路由：
- 写请求（INSERT、UPDATE、DELETE、BEGIN）全部打到主组（hostgroup 10）
- 简单读请求（SELECT）默认打到从组（hostgroup 20），但需注意：SELECT ... FOR UPDATE 必须回主组
- 配置示例（在 ProxySQL admin 接口执行）：
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (1, 1, '^SELECT.*FOR UPDATE$', 10, 1);<br>INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (2, 1, '^SELECT', 20, 1);<br>INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (3, 1, '^(INSERT|UPDATE|DELETE|REPLACE|SET)', 10, 1);<br>LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;
- 注意：ProxySQL 自身不感知双主谁是“当前主”，需配合监控脚本或 MGR 状态表动态调整 hostgroup 权重
Keepalived + VIP 方案只解决高可用，不解决负载均衡
Keepalived 绑定一个虚拟 IP（如 192.168.10.100），由主节点持有；主挂掉后 VIP 漂移到备节点，应用只需连这个 VIP —— 这解决了单点故障，但所有流量仍压在单一节点上：
- 它没有分流能力，谈不上“负载均衡”
- 切换过程有秒级中断（取决于 keepalived 的 check interval 和 failover timeout）
- 若强行用两个 Keepalived 实例各持一个 VIP，再让应用轮询两个 VIP，又回到前面“直连双主”的陷阱
- 正确做法是：Keepalived 保障 ProxySQL 或 MySQL Router 的高可用，而不是直接管 MySQL 实例
双主架构中最容易被忽略的一点：你永远无法靠复制机制本身判断“哪个节点当前更可靠”。SHOW SLAVE STATUS\G 显示 Slave_IO_Running: Yes 并不代表数据已应用，Seconds_Behind_Master 为 0 也不代表无延迟——尤其在大事务或网络抖动后，SQL thread 可能卡在 apply 阶段。真实可用性必须靠中间件探活 + 应用层超时兜底。
