4. Data Guard保护模式深入

Data Guard 的保护模式(Protection Mode)决定了主库在提交事务时,对备库日志写入的等待程度。它本质上是在“数据零丢失”与“主库可用性/性能”之间做取舍。Oracle 提供三种模式:最大保护(Maximum Protection)、最高可用(Maximum Availability)和最高性能(Maximum Performance)。理解它们的差异,关键要抓住三个变量:主库提交是否等待备库确认、等待的是内存(Standby Redo Log)还是磁盘、以及当备库不可用时主库会怎样反应。

三种模式的机制差异

在最大保护模式下,主库事务提交前必须确认至少一个同步备库已将重做日志写入Standby Redo Log(SRL),并且该备库返回确认。若没有可用备库,主库会直接关闭,以防止出现数据丢失。这种模式保证 RPO=0,但代价是主库可用性完全依赖备库。

最高可用模式同样要求同步传输,主库提交等待备库 SRL 写入确认,但有一个关键区别:当最后一个同步备库不可用时,主库自动降级为最大性能模式继续运行,而不是关闭。等备库恢复后,再自动回到最高可用。因此它兼顾了零丢失与主库可用性,是多数核心系统的推荐选择。

最高性能模式是默认模式,采用异步传输。主库提交事务时只写入本地 Online Redo Log 即返回成功,不等待备库确认。备库通过 ARCn 进程异步接收并应用日志。这种模式对主库性能影响最小,但在主库故障时可能丢失最后一段尚未传输的重做数据,RPO 通常大于 0。

三种保护模式的提交路径与备库故障行为对比 最大保护 Maximum Protection 主库提交事务 LGWR SYNC 等待备库 SRL 写入确认 RPO = 0 备库不可用? 是 → 主库关闭 主库不可用 业务中断 性能影响:最大 每次提交等待网络往返 RPO=0,RTO 取决于切换 最高可用 Maximum Availability 主库提交事务 LGWR SYNC 等待备库 SRL 写入确认 RPO = 0 备库不可用? 是 → 自动降级 主库继续运行 降级为最大性能 性能影响:中等 正常时同最大保护 降级后同最大性能 最高性能 Maximum Performance 主库提交事务 LGWR ASYNC 仅写本地 Online Redo 立即返回成功 备库异步接收 ARCn 传输 主库不受影响 RPO > 0 性能影响:最小 提交不等待备库 可能丢失最后日志

切换行为与状态转换

保护模式不仅影响提交路径,还决定了主备切换时的行为。在最大保护和最高可用模式下,由于备库已同步接收了所有重做日志,执行 SWITCHOVER 或 FAILOVER 时通常可以做到零数据丢失。但最大保护模式要求切换前必须确认所有同步备库都处于可用状态,否则切换可能失败或需要先降级。

最高可用模式在切换时更为灵活:如果原主库仍可访问,可以执行无损切换;如果原主库已崩溃,只要同步备库已收到全部日志,也可以执行零丢失故障切换。最高性能模式在故障切换时,备库上可能缺少最后一段未传输的日志,因此切换后需要评估数据丢失量,通常需要应用归档日志或接受一定 RPO。

需要特别注意的是,保护模式的修改不是随时可以进行的。从最高性能切换到最大保护或最高可用时,必须确保至少一个同步备库处于正常同步状态,否则 ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION 会报错。从最大保护降级到最高可用或最高性能则相对自由,因为这是降低约束。

性能影响与参数关系

保护模式对主库性能的影响,核心在于提交延迟。最大保护和最高可用模式下,每次事务提交都需要等待备库的网络往返和磁盘写入确认,因此主库的提交延迟至少增加一个网络 RTT 加上备库 SRL 的写入时间。在跨机房或跨城场景中,这个延迟可能从几毫秒上升到几十毫秒,对高并发小事务系统影响显著。

最高性能模式由于不等待备库,主库提交延迟几乎不受影响,但备库的日志应用延迟取决于网络带宽和备库应用能力。如果网络带宽不足或备库应用速度跟不上,日志积压会增大,故障时的数据丢失窗口也会扩大。

与保护模式直接相关的参数包括:LOG_ARCHIVE_DEST_n 中的 SYNC/ASYNC、AFFIRM/NOAFFIRM,以及 DB_UNIQUE_NAME、VALID_FOR 等。其中 AFFIRM 表示备库必须将日志写入磁盘后才确认,NOAFFIRM 则允许写入内存即确认。最大保护通常要求 SYNC AFFIRM,最高可用也建议 SYNC AFFIRM,最高性能则使用 ASYNC NOAFFIRM。

示例:查看当前保护模式与同步状态

-- 查看当前保护模式
SQL> SELECT protection_mode, protection_level FROM v$database;

PROTECTION_MODE      PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

-- 查看备库同步状态
SQL> SELECT dest_id, status, sync_status, affirm, async FROM v$archive_dest_status
     WHERE dest_id = 2;

   DEST_ID STATUS    SYNC_STATUS   AFFIRM   ASYNC
---------- --------- ------------- -------- -----
         2 VALID     SYNCHRONIZED  YES      NO

从上面的输出可以看到,SYNC_STATUS 为 SYNCHRONIZED 表示备库与主库保持同步,AFFIRM 为 YES 表示备库确认写入磁盘。如果 SYNC_STATUS 变为 NOT SYNCHRONIZED,在最高可用模式下主库会自动降级,此时 PROTECTION_LEVEL 会显示为 MAXIMUM PERFORMANCE,而 PROTECTION_MODE 仍保持 MAXIMUM AVAILABILITY。这个区别非常重要:MODE 是配置目标,LEVEL 是当前实际生效级别。

如何选择保护模式

选择保护模式时,建议从业务对 RPO 的要求、主库可用性容忍度、网络条件三个维度判断。如果业务要求零丢失且可以接受主库因备库故障而不可用,选最大保护;如果要求零丢失但主库必须持续可用,选最高可用;如果业务对少量数据丢失不敏感,且追求主库性能最优,选最高性能。

在实际生产环境中,最高可用模式往往是平衡点。它既保证了正常情况下的零丢失,又通过自动降级避免了备库故障导致主库不可用。但需要注意,降级期间如果主库发生故障,仍可能丢失数据,因此降级后应尽快恢复备库同步,并检查 V$DATAGUARD_STATS 中的 transport lag 和 apply lag,确认同步恢复后再切回最高可用。

提示:修改保护模式后,务必通过 V$DATABASE 的 PROTECTION_MODE 和 PROTECTION_LEVEL 两个字段确认实际状态,不要只看配置命令是否执行成功。同时检查 V$ARCHIVE_DEST_STATUS 中每个备库的 SYNC_STATUS,确保同步链路健康。