1、概述

在达梦数据库的学习过程中，实时归档/即时归档是一个被反复提及的重要特性，也是dm8实现集群搭建的基础，但在阅读文档和亲手搭建主备集群的过程中，我对实时归档和即时归档这两种归档类型的具体区别、运行逻辑产生了一定的疑问。为解决这些疑惑，我通过阅读文档，及与自身相对熟悉的mysql数据同步模式进行对比，总结成一套个人对于dm8实时/即时归档的理解并记录。本篇仅作为个人学习总结，若有错漏欢迎指正。

2、基本概念及个人理解

2.1 实时归档

实时归档（Realtime）将主库产生的 Redo 日志通过 MAL 系统传递到备库，实时归档是实时主备和 MPP 主备的实现基础。实时归档只在主库生效，一个主库可以配置 1~8 个实时备库。

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

以上为《DM8数据守护与读写分离集群》手册中，对于实时归档的概念解释。根据手册解释我们可以得知，实时归档的主要运行逻辑是将redo_log向备库传递放在整体数据写入逻辑的最前端，在确保备库获取到redo日志并响应后，再继续后续逻辑（写联机日志-本地归档）。

手册中描述的*备库收到 Redo 日志（RLOG_PKG）后标记为 KEEP_RLOG_PKG，将原 KEEP_RLOG_PKG 加入日志重演任务系统，并马上响应主库，不需要等待 Redo 日志重演结束后再响应主库。*这段逻辑实际上是实时归档+高性能模式配置的表现，我个人认为这种配置下，dm主备同步的逻辑与mysql的半同步有些许类似，同样是优先将记录修改日志（redo/binlog）传递给备库，并在备库响应后继续逻辑，且无需等待备库重演完成，仅需收到并响应即可。

实时归档+高性能，我个人理解应当是能够兼顾性能及数据一致性的配置，主库在写入本地联机日志及归档日志前，优先将redo日志送到了备库，即使这时主库因故挂掉，备库应用redo日志接管后，也能够保证数据的一致性。

那么实时归档+事务一致性呢？在这种配置下，主库不但需要等待redo日志发送到备库，还需要等待备库重演完成，因此在主库写入联机日志时，备库应当是已经完成了重演逻辑。若主库在刷盘前宕机，理论上备库能够以更快的速度接管，但同样的，由于主库需要等待从库重演完成再继续执行后续动作，不可避免的在性能方面会受到影响。依据前文逻辑，实时归档+事务一致性应当是更加适用于追求可用性及一致性而对性能要求较低的场景。

2.2即时归档

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

以上为《DM8数据守护与读写分离集群》手册中，对于即时归档的逻辑解释。我们可以看出，即时归档与实时归档一个显著的差异点在于联机日志文件的写入时机，即时归档实际上优先写入联机日志，再将redo日志发送给备库。

在默认情况下，即时归档为事务一致性模式，其含义与实时归档的事务一致性模式相同，即需要等待备库重演完成后，再响应commit。在这种情况下，有些接近于postgresql的主从同步流复制，即优先写本地联机日志（pg中则是wal日志），之后将日志传递至备库，等待备库重演完成后，再响应提交。同样的，pg也能够配置1-8个同步备库。

即时归档写本地联机日志的时机，要早于传送redo日志到备库上。因此可以假设一个场景，主库写入联机日志文件之后，突然发生故障（断网、机器挂掉），redo日志还来不及发送到备库。假设这次备库接管提为主库，实则丢失了一部分redo日志，后续主库再次拉起，集群内数据便会不一致。

3、总结

即时归档和实时归档作为dm8集群搭建中重要的依赖，配合高性能/事务一致两种模式的配置，能够适用于不同的场景，例如强调高并发高性能、强调可用性、强调数据一致性等不同的业务场景。

但结合即时归档的联机日志传送的逻辑，在极端场景下，可能无法保证备库接管后的数据一致性，造成主备数据不一致或组分裂。而实时归档模式实际上同样支持读写分离及事务一致性配置，因此我个人理解，在实际的生产过程中，可能采用实时归档是更能够保证集群状态的配置/