达梦数据库的归档模式介绍

几种归档模式

归档是实现数据守护系统的重要技术手段，根据功能与实现方式的不同，DM 数据库的归档可以分为 6 类：本地归档、远程归档、实时归档、即时归档、异步归档和同步归档。

其中，本地归档日志的内容与写入时机与数据库模式相关；主库 Redo 日志写入联机日志文件后，再进行本地归档；备库收到主库产生的 Redo 日志后，直接进行本地归档，同时启动 Redo 日志重演。

什么是归档模式？

归档模式是与非归档模式对应的，这两种模式是DM8数据库的两种运行状态。

• 非归档模式下，数据库只会将重做日志写入联机日志文件中进行存储；

• 归档模式下，数据库会**同时将重做日志写入联机日志文件和归档日志文件中分别进行存储**。

  无论是归档模式和非归档模式，联机日志文件都是存在的。

归档模式概览：

归档模式	说明
本地归档	在REDO日志写入联机日志文件后触发，将REDO日志写入到本地归档文件。由归档线程完成本地归档动作，最多可以设置8个本地归档。
实时归档	在写入REDO日志到联机日志文件之前，通过MAL系统发送REDO日志到远程服务器，远程服务器接收到REDO日志后，返回确认消息后，执行后续操作。发送REDO日志失败，或从备库返回的数据库模式不是STANDBY，将数据库切换为SUSPEND，阻塞所有REDO日志的写入操作。只能配置1个实时归档。这种归档类型只能用在主从备份集群中。
即时归档	即时归档在主库将REDO日志写入联机日志文件后，再通过MAL系统将REDO日志发送到备库。即时归档是读写分离集群的实现基础，与实时归档的主要区别是发送REDO日志的时间不同。一个主库可以配置1-8个即时备库。
异步归档	在设定的时间点或者每隔设定时间，启动归档REDO日志发送。设置定时归档，必须确保至少有一个本地归档。最多可以设置8个异步归档。
同步归档	同步归档的执行流程是，主库在归档日志刷盘后，将 Redo 日志发送到备库，备库收到 Redo 日志（RLOG_PKG）后将其加入日志重演任务系统，并马上响应主库，不需要等待 Redo 日志重演结束后再响应主库。
远程归档	远程归档专门用于 DMDSC 环境中。将写入本地归档的REDO日志信息，发送到远程节点，并写入远程节点的指定归档目录（共享存储）中。最多可以配置8个远程归档。

一、本地归档（Local）

Redo 日志本地归档（Local），就是将 Redo 日志写入到本地归档日志文件的过程。配置本地归档情况下，Normal/Primary 模式库在 Redo 日志写入联机 Redo 日志文件后，将对应的 RLOG_PKG 由专门的归档线程写入本地归档日志文件中。Standby 模式库收到主库产生的 Redo 日志后，直接进行本地归档，写入本地归档日志文件中，同时启动 Redo 日志重演。

与联机 Redo 日志文件可以被覆盖重用不同，本地归档日志文件不能被覆盖，写入其中的 Redo 日志信息会一直保留，直到用户主动删除；如果配置了归档日志空间上限，系统会自动删除最早生成的归档 Redo 日志文件，腾出空间。本地归档文件在配置的归档目录下生成并保存，如果磁盘空间不足，且没有配置归档日志空间上限（或者配置的上限超过实际空间），系统将自动挂起，直到用户主动释放出足够的空间后继续运行。

DM 提供了按指定的时间或指定的 LSN 删除归档日志的系统函数，分别为SF_ARCHIVELOG_DELETE_BEFORE_TIME 和SF_ARCHIVELOG_DELETE_BEFORE_LSN，但用户需要谨慎使用。例如，在守护系统中，如果备库故障了，主库继续服务，主库的日志在继续增长。此时如果删除尚未同步到备库的主库归档日志，那么备库重启之后，会由于备库收到的日志缺失导致主备库无法正常同步数据。

本地归档情况下，Normal/Primary/Standby三种模式下归档文件和Redo日志的区别？

模式	区别
Normal/Primary	归档日志文件保存的是当前节点产生的 Redo 日志，归档日志文件内容与联机日志内容保持一致。
Standby	备库归档日志文件保存的是主库产生的 Redo 日志，联机日志是重演日志以后，重新产生的。因此备库联机日志文件内容和归档日志文件内容是不完全一致的。

结论：各个节点的归档日志是一致的，但是归档日志和联机内容不一定一致。

注意

为了最大限度地保护数据，当磁盘空间不足导致归档写入失败时，系统会挂起等待，直到用户释放出足够的磁盘空间。当磁盘损坏导致归档日志写入失败时，系统会强制HALT。

二、远程归档（REMOTE ARCHIVE）

后面补充

三、实时归档（Realtime）

与本地归档写入保存在磁盘中的日志文件不同，实时归档（Realtime）将主库产生的 Redo 日志通过 MAL 系统传递到备库，实时归档是实时主备和 MPP 主备的实现基础。实时归档只在主库生效，一个主库可以配置 1~8 个实时备库。

实时归档的执行流程是，主库在 Redo 日志（RLOG_PKG）写入联机日志文件前，将 Redo 日志发送到备库，备库收到 Redo 日志（RLOG_PKG）后标记为 KEEP_RLOG_PKG，将原 KEEP_RLOG_PKG 加入日志重演任务系统，并马上响应主库，不需要等待 Redo 日志重演结束后再响应主库。主库收到备库的响应消息，确认备库已经收到 Redo 日志后，再将 Redo 日志写入联机日志文件中。

另外，实时归档也可以支持读写分离集群，实时归档也分为两种模式：事务一致模式和高性能模式，可以通过 dmarch.ini 中的ARCH_WAIT_APPLY 或 WAIT_APPLY 配置项来设置实时归档的模式。

• 事务一致模式

  • 主库事务提交触发 Redo 日志刷盘和即时归档，备库收到主库发送的 Redo 日志，重演完成后再响应主库。主库收到备库响应消息后，再响应用户的提交请求。事务一致模式下，同一个事务的 SELECT 语句无论是在主库执行，还是在备库执行，查询结果都满足 READ COMMIT隔离级要求。

• 高性能模式

  • 与实时归档一样，备库收到主库发送的 Redo 日志后，马上响应主库，再启动日志重演。高性能模式下，备库与主库的数据同步存在一定延时（一般情况下延迟时间非常短暂，用户几乎感觉不到），不能严格保证事务一致性。

这两种模式的具体含义和下一小节即时归档中的说明完全相同，区别仅在于配置为实时归档时，dmarch.ini 中的 ARCH_WAIT_APPLY 配置项默认值为 0，即采用高性能模式。

四、即时归档（Timely）

即时归档（Timely）在主库将 Redo 日志写入联机日志文件后，通过 MAL 系统将 Redo 日志发送到备库。即时归档与实时归档的主要区别是 Redo 日志的发送时机不同。一个主库可以配置 1~8 个即时备库。

根据备库重演 Redo 日志和响应主库时机的不同，即时归档分为两种模式：事务一致模式和高性能模式。即时归档模式可以通过dmarch.ini 中的 ARCH_WAIT_APPLY 或 WAIT_APPLY 配置项来设置。其中，ARCH_WAIT_APPLY 配置项默认值为 1，表示事务一致模式。

实时归档和即时归档比较

比较点	实时归档	即时归档
归档时机	写入联机日志前，发送到备库	写入联机日志后，发送到备库
备库数量	1~8	1~8
ARCH_WAIT_APPLY值	0（高性能模式）	1（事务一致模式）

五、异步归档（Async）

异步归档（Async）由主、备库上配置的定时器触发，根据异步备库的 KEEP LSN 信息，扫描本地归档目录获取 Redo 日志，并通过 MAL 系统将 Redo 日志发送到异步备库。异步备库的 Redo 日志重演过程与实时归档等其他类型的归档完全一致。

• 每个 Primary 或 Standby 模式的数据库最多可以配置 8 个异步备库
• Normal 模式下配置的异步备库会自动失效。
• 异步备库可以级联配置，异步备库本身也可以作为源库配置异步备库。

六、同步归档（Sync）

同步归档（Sync）在主库归档日志刷盘后，通过 MAL 系统将 Redo 日志发送到备库。同步备库的 Redo 日志重演过程与实时归档等其他类型的归档完全一致。备库收到 Redo 日志（RLOG_PKG）后将其加入日志重演任务系统，并马上响应主库，不需要等待 Redo 日志重演结束后再响应主库。一个主库可以配置 1~8 个同步备库。

❗七、归档模式的比较

比较项目	本地归档	实时归档	即时归档	异步归档	同步归档
备库数量	0	1~8	1~8	1~8	1~8
通过MAL传递数据	否	是	是	是	是
归档时机	写入联机日志后，再写入本地归档日志 文件	写入联机日志前，发送到备库	写入联机日志后，发送到备库	定时启动	写入归档日志后，发送到备库
归档写入(发 送 )	归档线程	日志刷盘线程	日志刷盘线程	异步归档线程	归档线程
数据来源	RLOG_PKG	RLOG_PKG	RLOG_PKG	本地归档文件	RLOG_PKG
失败处理	磁盘空间不足时，系统挂起等待用户释 放出足够的磁盘空间 。 磁盘损坏导致写入失败时，系统会强制HALT	Suspend数据库，保持归档状态不变，等待守护进程干预	Suspend数据库， 并设置归档为无效 状态，等待守护进程 干预	不做处理，等待下次触发继续发送	直接设置归档状 态为无效，不会 Suspend数据库
备库响应时机	无	事务一致模式：重演完成后响应；高性能模式：收到立即响应	事务一致模式：重演完成后响应；高性能模式：收到立即响应	收到立即响应	收到立即响应
源库模式	Primary Standby Normal	Primary	Primary	Primary Standby	Primary
目标库模式	无	Standby	Standby	Standby	Standby

注意

任意一个备库的实时归档/即时归档失败（即使其他备库归档成功了），主库都会切换为Suspend状态。

八、归档状态

本地归档、实时归档和即时归档均包含两种状态：Valid 和 Invalid。异步归档只有一种归档状态：Valid。而同步备库有三种归档状态，分别是 Valid，Invalid 和 Async_send。

• Valid 归档有效，正常执行各种数据库归档操作。
• Invalid 归档无效，主数据库不发送联机 Redo 日志到备数据库。
• Async_send 归档无效，但主库正在同步历史数据到同步备库。

在不同的归档类型中，归档状态转换时机不同。具体转换时机描述如下：

1. 主备库启动后，主库到所有备库的归档默认为 Valid 状态，守护进程 Open 主库前，根据主备库日志同步情况，将数据不一致备库的归档修改为 Invalid 状态。
2. 实时备库和即时备库故障恢复，从主库同步历史数据后，守护进程将主库修改为 Suspend 状态，并将主库到备库的归档状态从 Invalid 修改为 Valid。当守护进程再次 Open 主库后，主备库数据重新恢复为一致状态。
3. 同步备库故障恢复，主库开始同步历史数据时，将备库归档状态从 Invalid 修改为 Async_send，中间会将日志刷盘线程挂起确保备库能够追到和主库数据完全一致，并将主库到备库的归档状态从 Async_send 修改为 Valid，然后唤醒日志刷盘线程，主备库数据重新恢复为一致状态。
4. 主库发送日志到实时备库失败挂起，守护进程处理 Failover 过程中，将主库到备库的归档状态修改为 Invalid。
5. 主库发送即时归档失败后，直接将主库到备库的归档改为 Invalid 状态。
6. 主库发送同步归档失败后，直接将主库到备库的归档改为 Invalid 状态，并且不会有主库切换到 Suspend 状态的过程。
7. 异步归档始终保持 Valid 状态，一旦归档失败马上返回，等待下一次触发再继续发送。
8. 主库发现同步备库归档状态为 Invalid，且满足同步备库故障恢复的条件时，将主库到备库的归档状态从 Invalid 改为 Async_send，并开始同步历史数据到备库，同步完成后会将备库归档状态从 Async_send 修改为 Valid 有效状态。