mysql 8.4 不支持「双主双从」这种提法——它本质是逻辑错误，因双主（a↔b互为主从）与双从（c、d仅单向拉取）无法共存于同一gtid一致性和复制链路中，易触发er_gtid_executed_conflict等错误；实际应采用双主高可用（2节点active-active）+ 可选只读扩展从节点的架构。
MASTER（即 A→B + B→A），而“双从”若指另两个独立节点只拉取数据，就与双主冲突：复制链路无法同时满足双向同步 + 四节点全量一致，GTID 会直接报 ER_GTID_EXECUTED_CONFLICT 或 Cannot add or update a child row: a foreign key constraint fails 类错误。
你真正需要的，是 **双主高可用（2-node active-active）+ 可选只读扩展节点（1–2个 slave）**，Keepalived 仅接管双主中的 VIP，不参与从节点调度。
下面分三块讲清楚怎么做、为什么、容易栽在哪：
MySQL 8.4 双主配置必须错开自增和开启 GTID
MySQL 8.4 默认强制 GTID，gtid_mode=ON 和 enforce_gtid_consistency=ON 必须启用，否则 CHANGE MASTER TO ... MASTER_AUTO_POSITION=1 会失败。
两个主节点的自增必须隔离，否则 INSERT 不带主键时必然冲突：
-
auto_increment_offset：Node1 设为 1，Node2 设为 2 -
auto_increment_increment：统一设为 2（不能为 1） -
server_id：必须全局唯一，例如 8401 和 8402（不能用 IP 段数字，避免跨网段重复）
示例片段（/etc/my.cnf 中 [mysqld] 段）：
server_id = 8401 gtid_mode = ON enforce_gtid_consistency = ON auto_increment_offset = 1 auto_increment_increment = 2 log_bin = /var/lib/mysql/binlog/mysql-bin binlog_format = ROW
注意：binlog_format 必须为 ROW，STATEMENT 在双主下极易因函数/临时表导致不一致；skip_slave_start=1 建议加上，防止重启后自动启 slave 导致状态混乱。
Keepalived 不监控从节点，只管双主健康与 VIP 漂移
Keepalived 的 vrrp_script 检测脚本只能也只需检查本地 MySQL 是否可连、是否为 PRIMARY（通过 SELECT @@read_only 判断）、是否有复制延迟（SHOW SLAVE STATUS\G 中 Seconds_Behind_Master ≤ 5）。
常见错误是把检测脚本写成 ping 远程 MySQL 或查所有节点状态——VRRP 是单机视角协议，BACKUP 节点无法也不该感知对方的 slave 状态。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
关键配置项（/etc/keepalived/keepalived.conf）：
vrrp_script chk_mysql {
script "/etc/keepalived/check_mysql.sh"
interval 2
weight -5
fall 2
rise 1
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass mypass123
}
virtual_ipaddress {
192.168.3.30/24
}
track_script {
chk_mysql
}
}
注意：priority 在 BACKUP 节点要设为 90（低于 MASTER），且两节点 virtual_router_id 必须相同；advert_int 建议 ≤1s，否则故障切换超 3 秒。
额外从节点只能挂接在当前 VIP 所在主节点下
所谓“双从”，实际是：VIP 当前落在 Node1 上 → 所有从节点 CHANGE MASTER TO MASTER_HOST='192.168.3.30'；VIP 漂到 Node2 后，必须手动或通过 MHA/Orchestrator 类工具触发从节点重连，否则复制中断。
MySQL 8.4 不支持多源复制（Multi-Source Replication）自动 fallback 到另一主——START SLAVE IO_THREAD 会卡在连接拒绝，因为原主已不可写（read_only=ON 未生效或未配）。
安全做法：
- 从节点
read_only=ON+super_read_only=ON（防误写） - 用
mysqlrouter或应用层 DNS 轮询代替直连 VIP，避免从节点绑定失效 IP - 禁止从节点执行
STOP SLAVE; START SLAVE;—— 8.4 的 GTID 自动定位可能跳过事务，需用RESET SLAVE ALL+CHANGE MASTER TO ... GET_MASTER_PUBLIC_KEY=1重建
caching_sha2_password 认证插件，但 Keepalived 检测脚本或从节点连接时若没指定 --default-auth=mysql_native_password，会报 Plugin 'caching_sha2_password' cannot be loaded。务必在创建 repl 用户时显式指定：CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx';。
