主备切换不等于双主模式，需通过互为主从架构实现双向同步，核心是预防写冲突、闭环复制链路及保障状态一致；须配置不同server-id、配对auto_increment_offset/ increment、开启binlog与GTID；双向复制需两边互指binlog并授权；应用层须路由写请求或设计唯一逻辑键；切换实为流量调度，依赖监控自动完成。
主备切换本身不等于双主模式，但想通过主备切换实现双向同步，核心是把“一主一备”升级为“互为主从”的双主架构。这不是简单改个配置就能完成的，关键在数据写入冲突预防、复制链路闭环和状态一致性保障。
基础参数必须严格区分
两台服务器的 server-id 必须不同，且不能为 0；auto_increment_offset 和 auto_increment_increment 要配对设置，避免自增主键冲突：
- 节点 A：server-id = 1，auto_increment_offset = 1，auto_increment_increment = 2 → 生成 1,3,5…
- 节点 B：server-id = 2，auto_increment_offset = 2，auto_increment_increment = 2 → 生成 2,4,6…
同时确保 log-bin 开启，binlog_format = ROW（推荐），GTID 可选但建议开启（gtid_mode=ON + enforce_gtid_consistency=ON），便于后续故障定位和切换操作。
双向复制链路要完整打通
双主不是单向主从配两遍，而是两个方向都必须能独立建立并维持复制关系：
- 在节点 A 上执行 CHANGE MASTER TO 指向节点 B 的 binlog 文件名和位置，再 START SLAVE
- 在节点 B 上同样执行 CHANGE MASTER TO 指向节点 A 的 binlog 文件名和位置，再 START SLAVE
- 两边都要创建具备 REPLICATION SLAVE 权限的专用账号，且允许对方 IP 连接
- 务必检查 SHOW SLAVE STATUS\G 中的 Seconds_Behind_Master、IO_Running 和 SQL_Running 全为 Yes/0
应用层需配合规避写冲突
MySQL 双主不自动解决应用并发写同一张表同一行的问题。实际使用中必须有外部约束：
- 写请求尽量路由到固定节点（如用 VIP 或中间件绑定写入口），另一节点专注读+热备
- 若真需双点写，业务表必须有唯一逻辑标识（如带分片键的联合主键），避免主键或唯一索引冲突
- 禁止在双主环境中执行可能导致不一致的操作：如 DROP TABLE、TRUNCATE、非事务性 DDL
切换动作其实是状态确认，不是临时操作
双主运行稳定后，所谓“主备切换”更多是服务发现或流量调度层面的动作：
- 原写节点宕机时，监控系统检测到其 SQL_THREAD 停止或心跳丢失，自动将写流量切至另一节点
- 无需手动执行 STOP SLAVE / RESET SLAVE，只要复制链路正常，节点恢复后会自动追平数据
- 切换前后都应校验 SELECT MASTER_POS_WAIT() 或 GTID_EXECUTED 差值，确认无数据丢失
