几种归档模式
归档是实现数据守护系统的重要技术手段，根据功能与实现方式的不同，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 日志刷盘和
-
高性能模式
- 与
实时归档一样，备库收到主库发送的 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 归档无效，但主库正在同步历史数据到同步备库。
在不同的归档类型中，归档状态转换时机不同。具体转换时机描述如下：
- 主备库启动后，主库到所有备库的归档默认为 Valid 状态，守护进程 Open 主库前，根据主备库日志同步情况，将数据不一致备库的归档修改为 Invalid 状态。
- 实时备库和即时备库故障恢复，从主库同步历史数据后，守护进程将主库修改为 Suspend 状态，并将主库到备库的归档状态从 Invalid 修改为 Valid。当守护进程再次 Open 主库后，主备库数据重新恢复为一致状态。
- 同步备库故障恢复，主库开始同步历史数据时，将备库归档状态从 Invalid 修改为 Async_send，中间会将日志刷盘线程挂起确保备库能够追到和主库数据完全一致，并将主库到备库的归档状态从 Async_send 修改为 Valid，然后唤醒日志刷盘线程，主备库数据重新恢复为一致状态。
- 主库发送日志到实时备库失败挂起，守护进程处理 Failover 过程中，将主库到备库的归档状态修改为 Invalid。
- 主库发送即时归档失败后，直接将主库到备库的归档改为 Invalid 状态。
- 主库发送同步归档失败后，直接将主库到备库的归档改为 Invalid 状态，并且不会有主库切换到 Suspend 状态的过程。
- 异步归档始终保持 Valid 状态，一旦归档失败马上返回，等待下一次触发再继续发送。
- 主库发现同步备库归档状态为 Invalid，且满足同步备库故障恢复的条件时，将主库到备库的归档状态从 Invalid 改为 Async_send，并开始同步历史数据到备库，同步完成后会将备库归档状态从 Async_send 修改为 Valid 有效状态。
![XCTF：MISCall[WriteUP]](https://img-blog.csdnimg.cn/direct/fc9652c31d384e08b11c7a7209200a53.png)
