Java应用通过协同MySQL增强半同步复制（AFTER_SYNC模式）、连接层路由主库强读、故障转移JDBC配置及事务严谨性，可实现主从切换RPO=0。需确认MySQL启用rpl_semi_sync_master_wait_point=AFTER_SYNC，从库semi-sync开启且无延迟，Java层规避读写分离不一致，配合VIP或支持failover的JDBC URL，并强化事务与异常处理。
Java 应用本身不直接控制 MySQL 的复制机制，但可以通过合理配置数据库连接、事务管理与故障应对策略，配合 MySQL 侧已启用的增强型半同步复制（Lossless Semisynchronous Replication），实现主从切换时的数据零丢失（RPO=0）。关键在于：Java 是“使用者”，MySQL 是“保障者”，二者需协同设计。
确认 MySQL 已启用增强半同步复制
这是无损切换的前提。普通半同步（rpl_semi_sync_master_enabled=1）仅保证 relay log 写入，而增强半同步（MySQL 5.7+ 默认行为，或显式启用 rpl_semi_sync_master_wait_point=AFTER_SYNC）要求主库在binlog 持久化后、InnoDB 提交前等待至少一个从库确认接收并落盘 relay log——这样即使主库 crash，未提交的事务不会被客户端看到，也不会丢失。
- 检查主库是否启用增强模式：
SHOW VARIABLES LIKE 'rpl_semi_sync_master_wait_point';，返回值应为AFTER_SYNC - 确认半同步插件已安装且生效：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%'; - 确保至少一个从库的
rpl_semi_sync_slave_enabled=1，且SHOW SLAVE STATUS\G中Seconds_Behind_Master: 0和Slave_SQL_Running: Yes
Java 连接层规避“写后立刻读”一致性风险
即使复制无损，应用若在事务提交后立即向从库发起读请求，仍可能因复制延迟看到旧数据。这不是数据丢失，而是逻辑不一致，需在 Java 层规避：
- 对强一致性读（如刚写完查详情），强制走主库连接：可通过动态数据源路由（如 ShardingSphere、MyBatis Plus 多数据源）或自定义注解标记，跳过读写分离中间件
- 避免在同一个事务中混用主从连接；事务内所有 DML/DQL 必须绑定同一物理连接（通常为主库）
- 使用
spring.datasource.hikari.connection-init-sql=SELECT 1确保连接建立时能快速探活，减少故障发现延迟
主从切换时 Java 应用的容错配合
MySQL 自动切换（如 MHA、Orchestrator）或手动提升从库为主库后，Java 应用需快速感知并重连新主库：
立即学习“Java免费学习笔记（深入）”；
- 使用支持故障转移的 JDBC URL，例如：
jdbc:mysql://host1:3306,host2:3306/db?loadBalanceAutoCommitStatementThreshold=5&failOverReadOnly=false&autoReconnect=true（注意：MySQL Connector/J 8.0+ 推荐用xdevapi或replicationConnection方式） - 配合 DNS 或 VIP（如 Keepalived 虚拟 IP）：Java 连接固定 VIP，底层由 VIP 漂移到新主库，应用无需改配置，只需确保连接池支持自动重连和超时重试
- 在应用启动/健康检查中加入
SELECT @@server_id, @@read_only校验当前连接是否为可写主库，避免误连只读从库
事务与异常处理强化数据安全边界
无损复制不能替代应用层事务严谨性。Java 必须确保：
- 所有写操作必须包裹在 Spring
@Transactional或原生 JDBC 事务中，禁止 auto-commit 模式下的分散 update - 捕获
SQLTimeoutException、CommunicationsException等网络类异常，触发业务级补偿（如幂等重试、本地消息表、Saga 分布式事务） - 避免长事务：半同步会阻塞主库提交，若事务过大或网络抖动，会导致客户端超时；建议单事务控制在 1 秒内完成
