DM 数据守护四种归档对比

在 DM 数据守护系统中，主库产生的 Redo 日志需要传输到备库，并由备库进行日志接收、保存和重演。

日志传输是否及时、主库需要等待到哪个阶段、链路故障后如何处理，都会影响主备数据差距、事务提交性能和故障恢复能力。

DM 提供实时归档、即时归档、同步归档和异步归档四种与备库相关的归档方式。它们都能将 Redo 日志传输到其他实例，但设计目标并不相同。

实时归档和即时归档主要用于建立可切换、可接管的主备关系；
同步归档和异步归档通常用于增加辅助备库、扩展容灾层级，目标库一般不直接参与自动接管。

本文整理这四种归档方式，重点对比说明以下内容：

日志在什么时间发送；
主库等待备库完成到哪一步；
备库是否等待日志重演完成后再响应；
归档链路异常后主库和备库如何处理；
不同归档方式对 RPO、RTO 和部署场景的影响；

本文不是完整的数据守护搭建手册，配置片段只保留与归档方式有关的关键项目。实例名称、网络地址、端口、OGUID、本地归档路径和监视器配置仍需根据实际环境补充。不同版本的参数和行为可能存在差异，生产环境应以当前版本的官方文档和实际测试结果为准。

1. 四种归档方式

实时归档、即时归档、同步归档和异步归档，这四种归档都属于 Redo 日志传输机制，不等同于数据库备份。数据库备份用于形成可独立保存和还原的数据副本；归档链路主要用于将数据库运行过程中产生的 Redo 日志持续或定期传输到其他实例。

从守护系统中的职责看，可以分为两类：

实时归档和即时归档：通常配置在全局守护组中，备库满足条件时可以参与主备切换或故障接管。
同步归档和异步归档：通常配置为本地守护，用作辅助备库，不直接参与全局守护组的自动切换。

四种方式的差别主要需要比较的是日志发送时机、响应条件、故障处理方式和目标库职责。

对比总结如下：

对比项	实时归档 `REALTIME`	即时归档 `TIMELY`	同步归档 `SYNC`	异步归档 `ASYNC`
主要用途	实时主备、同城高可用，也可用于读写分离	读写分离、需要缩小主备可见数据差距的场景	增加持续同步的辅助备库	异地容灾、延迟同步、级联容灾
日志发送时机	在主库写入当前联机日志前发送	主库先写入联机日志，再发送到备库	本地归档日志刷盘后立即发送	定时器触发后扫描本地归档并发送
是否依赖定时器	否	否	否	是
默认响应条件	备库收到日志后响应，不等待重演完成	备库重演完成后响应	备库收到日志后响应，不等待重演完成	备库收到日志后响应，不等待重演完成
默认模式	高性能模式	事务一致模式	固定为收到后响应	固定为收到后响应
是否具有 `KEEP_RLOG_PKG`	有	没有	没有	没有
链路异常后的处理	可能使主库进入 `SUSPEND`，具体取决于切换模式和日志同步策略	可能使主库进入 `SUSPEND`，具体取决于切换模式和日志同步策略	归档可转为 `INVALID`，链路恢复后发起异步追赶	本次同步失败后等待后续定时任务继续发送
是否直接参与主备切换	在全局守护配置并满足条件时可以	在全局守护配置并满足条件时可以	按通常的本地守护配置时不参与	按通常的本地守护配置时不参与
单个源库可配置数量	1～8 个	1～8 个	1～8 个	最多 8 个，并支持级联

表中的“默认”表示未通过相关参数改变行为时的情况。实时归档的发送顺序还会受到 ARCH_SEND_POLICY 影响，实时和即时归档的故障处理会受到 DW_MODE、RLOG_SYNC_MODE 和监视器状态等因素影响。

2. 不同归档的日志流转过程

2.1 实时归档

实时归档的主要特点是：主库优先将当前日志包发送到实时备库，再完成本地联机日志写入。

在 ARCH_SEND_POLICY = 0 且采用默认高性能模式时，流程可以概括为：

主库生成 Redo 日志
        ↓
发送到实时备库
        ↓
备库接收并响应
        ↓
主库写入联机日志
        ↓
备库继续进行日志重演

实时备库接收到的部分日志，可能还没有写入原主库的联机日志。这部分日志通过 KEEP_RLOG_PKG 机制保留。在主备切换或故障接管过程中，备库会先处理需要应用的 KEEP_RLOG_PKG，再继续完成后续操作。

即时备库没有这一机制，因此 KEEP_RLOG_PKG 是区分实时归档和即时归档的重要特征之一。

实时归档默认采用高性能模式：

ARCH_WAIT_APPLY = 0

此时，备库收到日志后即可响应主库，不需要等待日志重演完成。这样可以减少重演时间对事务提交的影响，但备库已经接收到的日志不一定已经完成重演，因此备库查询结果可能暂时落后于主库。

如果设置为事务一致模式：

ARCH_WAIT_APPLY = 1

备库需要在日志重演完成后再响应主库。该模式会增加事务提交等待时间，而且存在使用限制：手动切换模式下，该设置对实时归档不生效；实时归档的 DMDSC 数据守护环境也不支持将其设置为 1。

实时归档还支持 ARCH_SEND_POLICY 参数：

ARCH_SEND_POLICY = 0：发送日志后立即等待备库响应，再写入主库联机日志；
ARCH_SEND_POLICY = 1：发送日志后先写入主库联机日志，再等待备库响应，使本地刷盘和等待响应近似并行。

ARCH_SEND_POLICY = 1 可以减轻备库响应时间对主库日志刷盘线程的影响，但在自动接管环境中可能增加集群分裂风险，不能只根据性能测试结果直接启用。

2.2 即时归档

即时归档与实时归档的主要区别，是主库先完成本地联机日志写入，再将日志发送到即时备库。默认事务一致模式下，流程如下：

主库生成 Redo 日志
        ↓
主库写入联机日志
        ↓
发送到即时备库
        ↓
备库接收并重演
        ↓
备库响应主库

即时归档默认采用事务一致模式：

ARCH_WAIT_APPLY = 1

备库收到日志后，需要完成日志重演，再向主库返回响应。主库收到响应后，才能继续完成对应的提交确认。与高性能模式相比，这种方式可以缩小主库提交成功与备库能够读到相应数据之间的时间差，更适合对备库查询及时性要求较高的读写分离场景。

其代价是网络往返时间和备库日志重演时间都会进入事务等待路径。如果网络时延较高，或者备库重演发生堆积，主库事务提交延迟会明显增加。

如果业务更重视写入性能，并且可以接受备库查询存在短暂延迟，可以设置：

ARCH_WAIT_APPLY = 0

此时，备库收到日志后立即响应，日志在后台继续重演。该配置不能只根据吞吐量决定，还应测试备库查询延迟和故障接管前的日志积压情况。

2.3 同步归档

同步归档在主库本地归档日志刷盘后，立即通过 MAL 将日志发送到同步备库，不依赖定时器。

主库写入联机日志
        ↓
生成并刷盘本地归档
        ↓
发送到同步备库
        ↓
备库接收并响应
        ↓
备库继续进行日志重演

同步备库收到日志后，会将日志加入重演任务系统并立即响应，不等待重演完成。因此，“同步归档”中的“同步”主要表示主库在本地归档产生后立即发送，不表示主库必须等待备库重演完成。

同步归档常用于在现有实时或即时主备之外增加辅助备库。该备库可以持续接收日志，但通常配置为本地守护，不承担自动接管职责。

当同步备库故障或链路中断时，对应归档状态可能变为 INVALID。主库按照 ARCH_RECOVER_TIME 设置的间隔检查同步备库状态；通信恢复且满足条件后，主库通过异步恢复方式补发历史日志。恢复期间，状态一般会经历：

INVALID → ASYNC_SEND → VALID

2.4 异步归档

异步归档不随每次事务立即发送日志，而是由定时器触发。触发后，源库根据异步备库的 KEEP LSN，从本地归档目录中查找备库缺少的日志，并通过 MAL 发送到目标库。

主库产生 Redo 日志
        ↓
日志进入本地归档
        ↓
定时器满足触发条件
        ↓
根据 KEEP LSN 扫描缺失日志
        ↓
发送到异步备库
        ↓
备库接收并重演

异步归档必须满足两个基础条件：

源库已经配置至少一路本地归档；
dmtimer.ini 中存在对应定时器，并且 TIMER_INI = 1。

异步备库收到日志后，会将日志加入重演任务系统并立即响应，不等待日志重演完成。

异步归档支持在主备两端配置同一个异步目标，也支持级联部署。发生主备切换后，可以由新的源库继续向异步备库发送归档日志。由于日志发送由定时器控制，异步备库的数据差距主要受到定时器间隔、额外发送延迟、网络传输速度和日志重演速度影响。

3. 归档相关配置和默认行为

3.1 基础开关

使用数据守护归档前，需要启用 MAL 和归档功能：

MAL_INI = 1
ARCH_INI = 1

使用异步归档时，还需要启用定时器：

TIMER_INI = 1

同步归档和异步归档都依赖本地归档日志。实际配置时，应同时规划本地归档路径、空间上限和保留时间，避免历史日志被清理后无法补齐备库缺口。

3.2 实时归档

ARCH_WAIT_APPLY = 0

[ARCHIVE_REALTIME]
ARCH_TYPE = REALTIME
ARCH_DEST = GRP1_RT_02

如果只希望某一个目标使用事务一致模式，可以使用该归档目标下的 WAIT_APPLY 覆盖全局设置：

[ARCHIVE_REALTIME]
ARCH_TYPE = REALTIME
ARCH_DEST = GRP1_RT_02
WAIT_APPLY = 1

3.3 即时归档

ARCH_WAIT_APPLY = 1

[ARCHIVE_TIMELY]
ARCH_TYPE = TIMELY
ARCH_DEST = GRP1_RWW_02

即时归档默认使用事务一致模式。若将 ARCH_WAIT_APPLY 或该目标下的 WAIT_APPLY 设置为 0，则改为高性能模式。

3.4 同步归档

[ARCHIVE_SYNC]
ARCH_TYPE = SYNC
ARCH_DEST = GRP1_SYNC_01
ARCH_RECOVER_TIME = 60

ARCH_RECOVER_TIME 的单位为秒，取值范围为 1～86400，默认值为 60。它表示同步归档失效后，主库检查归档状态并尝试启动异步恢复的时间间隔。

3.5 异步归档

[ARCHIVE_ASYNC]
ARCH_TYPE = ASYNC
ARCH_DEST = GRP1_ASYNC_01
ARCH_TIMER_NAME = RT_TIMER
ARCH_SEND_DELAY = 0

其中：

ARCH_TIMER_NAME 必须与 dmtimer.ini 中的定时器名称一致；
ARCH_SEND_DELAY 表示额外延迟发送时间，单位为分钟；
ARCH_SEND_DELAY = 0 表示不启用额外延迟，不代表异步归档会立即发送；
实际发送时间仍由定时器的触发条件决定。

下面是一个每天零点触发一次的定时器示例：

[RT_TIMER]
TYPE = 2
FREQ_MONTH_WEEK_INTERVAL = 1
FREQ_SUB_INTERVAL = 0
FREQ_MINUTE_INTERVAL = 0
START_TIME = 00:00:00
END_TIME = 23:59:59
DURING_START_DATE = 2026-01-01 00:00:00
DURING_END_DATE = 9999-12-31 23:59:59
NO_END_DATE_FLAG = 1
DESCRIBE = ASYNC ARCHIVE TIMER
IS_VALID = 1

该示例只说明定时器与异步归档的关联方式。生产环境不能直接照搬每日一次的频率，应根据业务允许的数据丢失窗口确定触发周期。

3.6 守护进程类型

实时和即时主备通常配置为全局守护：

[GRP1]
DW_TYPE = GLOBAL
DW_MODE = AUTO

同步和异步辅助备库通常配置为本地守护：

[GRP1]
DW_TYPE = LOCAL
DW_MODE = MANUAL

DW_TYPE = LOCAL 时，目标库不属于全局自动切换链路。即使数据库持续接收日志，也不能据此认为它能够直接参与自动接管。

3.7 参数总结

参数	适用范围	默认值或常见值	作用
`ARCH_WAIT_APPLY`	实时、即时归档	实时默认 `0`，即时默认 `1`	控制备库收到日志后，是否等待重演完成再响应主库
`WAIT_APPLY`	单个实时或即时目标	未配置时继承 `ARCH_WAIT_APPLY`	覆盖某一个归档目标的等待策略
`ARCH_SEND_POLICY`	实时归档	默认 `0`	控制主库发送实时日志后，等待备库响应与写入本地联机日志的先后关系
`ARCH_RECOVER_TIME`	同步归档	默认 60 秒	控制同步归档失效后的检查和异步恢复间隔
`ARCH_TIMER_NAME`	异步归档	无默认定时器名称	关联异步归档使用的定时器
`ARCH_SEND_DELAY`	异步归档	默认 `0` 分钟	在定时器触发基础上增加发送延迟
`RLOG_SYNC_MODE`	实时、即时日志发送故障处理	默认 `0`	`0` 表示发送失败后进入 `SUSPEND` 并进入故障处理流程；`1` 表示直接将备库归档失效，仅在非自动切换模式下有效

4. 链路故障时的处理差异

4.1 实时归档和即时归档

实时和即时备库通常属于主备高可用链路。在默认日志同步策略下，主库向有效备库发送日志失败后，可能进入 SUSPEND 状态，由守护进程继续判断是否需要执行故障处理。

具体处理结果与以下因素有关：

DW_MODE 是自动切换还是手动切换；
是否存在正常工作的确认监视器；
RLOG_SYNC_MODE 的设置；
主库、备库和守护进程的实际状态；
故障发生前归档状态是否为 VALID。

因此，不能简单写成“实时或即时备库故障后，主库一定挂起”或“主库一定继续运行”。在手动切换模式下，或者采用不同日志同步策略时，归档可能被直接设置为无效，主库继续提供服务；在自动切换模式和默认策略下，则可能进入 SUSPEND 和后续故障处理流程。

备库能否执行正常 TAKEOVER，还需要满足归档有效、数据库状态正常、守护进程控制信息有效等条件。强制接管不会执行同等级别的一致性检查，可能造成数据丢失或守护组分裂，应作为异常情况下的人工处置手段。

4.2 同步归档

同步备库通常是辅助备库。链路中断后，对应归档状态可以转为 INVALID，主库不需要长期等待该辅助备库恢复。

链路恢复后，主库根据 ARCH_RECOVER_TIME 周期检查同步备库状态，并通过历史归档补发缺失日志。补发期间归档状态为 ASYNC_SEND，追平后恢复为 VALID。

如果主库本地已经不存在同步备库所需的历史归档，自动追赶可能无法完成，此时需要重新准备备库数据。

4.3 异步归档

异步归档本身就是周期性发送。某次同步任务失败后，源库通常等待后续定时器再次触发，或者在链路恢复后重新进行同步。

异步恢复能否完成，取决于源库是否仍保留目标库缺少的本地归档。如果缺失日志已经被删除，仅恢复网络连接不能补齐数据，需要通过备份还原等方式重新准备异步备库。

5. RPO 和 RTO 的影响

RPO 表示发生故障时可以接受的数据丢失范围，RTO 表示业务从故障发生到恢复服务所需的时间。归档类型会影响 RPO 和 RTO。

5.1 实时归档

在归档状态有效、采用默认实时发送策略、仅主库发生故障且备库日志完整的前提下，实时归档可以将已确认事务的数据丢失风险控制在较低水平。

高性能模式下，备库已经接收日志，但可能尚未完成重演。日志接收进度主要影响数据是否保留，日志重演进度主要影响备库查询延迟和接管时间。因此，即使 RPO 较小，重演积压仍可能延长 RTO。

5.2 即时归档

即时归档默认等待备库完成日志重演后再响应主库。对于已经向客户端确认成功的事务，备库通常已经完成相应日志重演，因此接管前的待重演量通常小于高性能模式。

但即时归档是先写主库联机日志、再向备库发送。如果故障发生在本地写入完成但日志尚未传输的阶段，原主库和备库之间可能存在差异。正常接管和强制接管的检查条件也不同，不能把即时归档简单表述为任何故障下都绝对零数据丢失。

5.3 同步归档

同步备库正常且归档状态为 VALID 时，数据通常能够持续接近主库。同步备库故障后，主库可以继续产生新的业务数据，副本差距会随故障持续时间增加。

同步备库通常不参与自动接管，因此其 RTO 还包含人工判断、补齐日志、转换角色和应用切换等时间。它更适合用作辅助数据副本，不应替代实时或即时主备承担主要高可用职责。

5.4 异步归档

异步归档的 RPO 主要由以下因素共同决定：

定时器触发间隔
+ ARCH_SEND_DELAY 额外延迟
+ 网络传输积压
+ 尚未发送的日志量

备库已经接收但尚未重演的日志一般不会直接增加数据传输层面的 RPO，但会增加备库可见数据延迟和启用备库所需的时间。

异步备库通常需要人工确认和切换，RTO 还受到日志补发、日志重演、应用连接调整和容灾流程熟练程度影响。

6. 选型建议

业务需求	更适合的归档方式	说明
需要同城主备高可用和自动接管	实时归档	默认高性能模式，提交性能相对较好，但需要关注备库重演积压
备库承担查询，并希望主库提交后尽快读到对应数据	即时归档	默认等待备库重演，查询及时性较好，但事务提交时延更高
已有主备高可用，还需要增加持续同步的辅助副本	同步归档	不依赖定时器，副本更新较及时，通常不参与自动接管
跨机房、远距离网络或允许明确的数据同步窗口	异步归档	不将远端网络持续放入事务等待路径，但 RPO 受定时器和传输积压影响

实际生产环境可以组合使用：

主库
├─ 实时备库或即时备库：承担主要高可用和业务接管
├─ 同步备库：提供近端辅助副本
└─ 异步备库：提供异地容灾或下一级级联同步

选择时应依次确认以下条件：

目标库是否必须参与自动接管；
业务是否允许网络和备库重演时间进入事务提交路径；
业务允许的数据丢失窗口有多大；
备库是否承担只读查询；
本地归档空间能否覆盖最长故障和断网时间。

DM守护集群四种归档方式对比