主备状态不一致需从日志同步、进程运行、数据应用三层面持续监控；关键包括检查归档传输链路、RFS进程、回放模式、SCN/LSN增长趋势及底层资源瓶颈。
主备状态不一致不是等告警响了才去查，而是要从日志同步、进程运行、数据应用三个层面持续盯住关键信号。真正有效的预警，靠的是对“细微偏差”的敏感，而不是等延迟拉到几分钟才触发。
看日志传输链路是否断点
主库生成日志、网络传输、备库接收，三步缺一不可。只要其中任一环节卡住，后续所有指标都会失真。
- 在主库查 v$archive_dest_status，重点关注 STATUS（必须为 VALID）、ERROR（非空即故障）、TRANSMIT_MODE（推荐 ASYNC 或 SYNC）
- 在备库查 v$archive_gap，只要返回记录，说明有归档日志没收到——这是最硬的不一致证据，比 SCN 差值更严重
- 检查 RFS（Remote File Server）进程是否存活：Linux 下执行 ps -ef | grep rfs，缺失则网络或监听配置异常
查关键进程是否真实运行
很多“看起来正常”的状态，其实是进程假死或卡在某个环节。不能只信 show slave status\G 里的 Slave_IO_Running 和 Slave_SQL_Running 字段。
- MySQL 中，Seconds_Behind_Master 为 NULL 或 0 不代表健康，需结合 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 是否持续推进来判断
- Oracle Data Guard 中，确认备库 RECOVERY_MODE 是 MANAGED REAL TIME APPLY 而非 MANAGED STANDBY；后者天然存在分钟级延迟，误判风险高
- 达梦或 YashanDB 等国产库，用 gstack 抓取回放线程栈，看是否长时间停留在 IO 等待或锁等待上
比对数据应用进度是否收敛
SCN、LSN、ASN 这些数字本身没有绝对意义，要看它们是否在合理范围内缓慢增长，而非突然停滞或跳跃式扩大。
- Oracle 推荐查 v$dataguard_stats 中的 apply lag，单位是时间间隔（如 +00 00:02:18），比 SCN 差值更直观；注意该视图必须在主库查
- YashanDB 关注 Redo Remain 和预估 Remain Time，OPEN 后仍持续不降，大概率是磁盘写入瓶颈
- MySQL 可配合 pt-table-checksum 定期校验核心表，发现行级不一致早于复制延迟暴露
监控底层资源是否拖慢回放
主备不一致常是结果，IO、CPU、锁竞争才是根因。光盯数据库层，容易漏掉真正瓶颈。
- 用 iostat -x 1 观察备库磁盘：%util > 95%、await > svctm * 2、avgqu-sz > 4 都是明显过载信号
- 检查备库是否开启并行回放（如 MySQL 的 slave_parallel_workers > 0），但未配合适当的 slave_parallel_type
- 对比主备库相同时间段的 CPU 使用率与锁等待事件（如 Oracle 的 v$session_wait），若备库频繁出现 log file sync 或 enq: TX row lock contention，说明事务回放受阻
