确保主备切换零丢失的关键是“切得稳”，需数据库层（强同步校验）、写入策略（持久化语义）、监控校验（闭环验证）和切换流程（受控执行）四层协同；各数据库均有明确就绪信号，必须程序化确认延迟为0、事务已重放、角色已就绪后方可切换。
要确保主备切换过程中数据一致且零丢失，关键不是“切得快”，而是“切得稳”——前提是同步状态可靠、写入语义严格、切换动作受控。这不是单点配置能解决的问题，需从数据库层、写入策略、监控校验和切换流程四方面协同保障。
数据库层必须满足强同步前提
主备延迟大或状态未确认时强行切换，等于主动丢数据。各数据库有明确的就绪信号，必须校验通过才可触发切换：
- Oracle：主库
SWITCHOVER_STATUS为TO STANDBY或SESSIONS ACTIVE，备库为TO PRIMARY；归档传输模式必须为SYNC，且v$archive_dest_status中STATUS=VALID、ERROR为空 - MySQL：启用半同步（
rpl_semi_sync_master_enabled=ON），并设rpl_semi_sync_master_wait_for_slave_count=1，确保至少一个备库确认接收才提交 - PostgreSQL：
synchronous_commit = remote_apply，同时用pg_stat_replication检查sync_state='sync'且replay_lsn已追平主库pg_current_wal_lsn() - MongoDB：写操作必须显式指定
writeConcern: { w: "majority", j: true }，禁用默认的w: 1；服务端storage.journal.enabled必须为true
写入行为必须绑定持久化语义
即使底层同步可靠，应用若用弱写入策略，照样丢数据：
- 避免使用
w: 1（MongoDB）、sync_binlog=0（MySQL）或fsync=off（PostgreSQL）等配置 - MySQL建议开启GTID，并设
sync_binlog=1与innodb_flush_log_at_trx_commit=1，主库崩溃也不丢binlog与redo - 所有写请求应带超时（如
wtimeout=5000），防止因节点临时不可用而无限等待
切换前必须完成状态闭环验证
不能依赖“看起来同步了”，而要程序化确认：
- 检查备库延迟值是否真实为0：MySQL看
Seconds_Behind_Master=0且SQL_Running=Yes；PG看pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()；MongoDB用rs.printSecondaryReplicationInfo()比对optimeDate - 主库切只读后，需再次轮询确认所有待同步事务已在备库重放完毕，再执行提升
- 切换脚本中嵌入校验逻辑，例如MySQL执行
SELECT MASTER_POS_WAIT()确认位置追平，失败则中止
中间件与应用需配合无感承接
数据库层不出错，不代表业务不中断：
- 客户端连接必须经由中间件（如ProxySQL、ShardingSphere）或VIP，而非直连IP；切换时由中间件自动重路由，应用无需感知
- 应用代码需具备重连+幂等重试能力，尤其防范选举窗口期（如MongoDB旧主未及时降级）产生的“幽灵写入”
- 禁止在切换期间执行
DROP TABLE、TRUNCATE、非事务DDL等破坏性操作，这类操作无法被复制或回滚
不复杂但容易忽略
