DM守护集群介绍

客观花絮说

已于 2024-08-05 11:11:08 修改

阅读量796

点赞数 31

分类专栏：达梦数据库文章标签：数据库

于 2024-08-05 10:35:31 首次发布

本文链接：https://blog.csdn.net/qq_56594426/article/details/140920329

版权

达梦数据库专栏收录该内容

8 篇文章 0 订阅

订阅专栏

DM守护集群

DM守护集群是数据库异地容灾的首选方案

主备库可以快速切换。

实时主备：一个主库以及一个或多个配置了实时归档的备库组成。

实时主备系统：主备提供完整的功能，备库提供只读服务。

一、数据守护原理

DM 数据守护 (Data Watch) 的实现原理非常简单：将主库（生产库）产生的 REDO 日志传输到备库，备库接收并重新应用 REDO 日志，从而实现备库与主库的数据同步。DM 数据守护的核心思想是监控数据库状态，获取主、备库数据同步情况，为 REDO 日志传输与重演过程中出现的各种异常情况提供一系列的解决方案。

DM 数据守护系统主要由主库、备库、REDO 日志、REDO 日志传输、REDO 日志重演、守护进程 (dmwatcher)、监视器 (dmmonitor) 组成，如下图所示：

在这里插入图片描述

数据库 (Database) 是一个文件集合（包括数据文件、临时文件、重做日志文件和控制文件），保存在物理磁盘或文件系统中。
数据库实例 (Instance) 是一组操作系统进程（或者是一个多线程的进程）以及一些内存。通过数据库实例，可以操作数据库，一般情况下，我们访问、修改数据库都是通过数据库实例来完成的。

1.1 主库

Primary 模式，提供完整数据库服务的实例，一般来说主库是用来直接支撑应用系统的生产库。

1.2 备库

Standby 模式，提供只读数据库服务的实例。备库除了用于容灾，还可以提供备份、查询等只读功能，并且备库还支持临时表的 Insert/Delete/Update 操作，备库支持临时表修改主要基于以下两个因素：

临时表数据的修改不会产生 REDO 日志，主库对临时表的修改无法同步到备库；
可以提供更大灵活性，适应更多应用场景。

根据数据同步情况，备库又可以分为可切换备库和不可切换备库。可切换备库是指，主备库之间数据完全同步，主库发生故障、备库切换为主库后，不会造成任何数据丢失的备库。

1.3 REDO 日志

REDO 日志记录物理数据页内容变动情况，是数据库十分重要的一个功能，在数据库系统故障（比如服务器掉电）重启时，利用 REDO 日志可以把数据恢复到故障前的状态。

REDO 日志也是数据守护的实现基础，数据库中 Insert、Delete、Update 等 DML 操作以及 Create TABLE 等 DDL 操作最终都会体现为对某一个或者多个物理数据页的修改，因此备库通过重做 REDO 日志可以与主库数据保持一致。

1.4 REDO 日志传输

主备库之间的 REDO 日志传输，以日志包 RLOG_PKG 为单位，主库通过 MAL 系统发送 REDO 日志到备库。各种不同数据守护类型的区别，就在于主库日志包 RLOG_PKG 的发送时机，以及备库收到 REDO 日志后的处理策略。

1.5 REDO 日志重演

REDO 日志重演的过程，就是备库收到主库发送的 REDO 日志后，在物理数据页上，重新修改数据的过程。REDO 日志重演由专门的 REDO 日志重演服务完成，重演服务严格按照 REDO 日志产生的先后顺序，解析 REDO 日志、修改相应的物理数据页，并且重演过程中备库会生成自身的 REDO 日志写入联机日志文件。

1.6 守护进程

守护进程 (dmwatcher) 是数据守护系统的核心工具，监控数据库实例的运行状态和主备库数据同步情况，在出现故障时启动各种处理预案。守护进程是各种消息的中转站，接收数据库实例、其他守护进程、以及监视器发送的各种消息；同时，守护进程也会将收到的数据库实例消息转发给其他守护进程和监视器。守护进程必须和被守护的数据库实例部署在同一台机器上。

1.7监视器

监视器 (dmmonitor) 用来监控守护系统内守护进程、数据库实例信息，执行用户输入命令、监控实例故障、实现自动切换等。监视器一般配置在数据库实例和守护进程以外的机器上。

1.7.1 监视器类型

监视器分为两种类型：普通监视器和确认监视器。监视器类型由配置文件（dmmonitor.ini）的 MON_DW_CONFIRM 参数来确定。MON_DW_CONFIRM 参数的默认值是 0，表示普通监视器；MON_DW_CONFIRM 参数值为 1 时，表示确认监视器。

用户可根据实际需要，选择是否配置监视器或配置多少个监视器。普通监视器和确认监视器可以在系统中同时存在，也可以只配置其中一种。故障自动切换模式下，必须配置确认监视器。

为了防止单实例确认监视器出现故障，建议用户将确认监视器配置多实例形式。

1.7.1.1 普通监视器

一个数据守护系统中，最多允许同时启动 10 个普通监视器。多个普通监视器之间的关系为相互独立，互不干扰。

所有普通监视器都可以接收守护进程消息，获取守护系统状态，也可以执行各种监控命令。所有监视器都可以发起 Switchover 等命令，但守护进程一次只能接收一个监视器的命令，在一个监视器命令执行完成之前，守护进程收到其他监视器发起的请求，会直接报错返回。

1.7.1.2 确认监视器

确认监视器和普通监视器的区别在于，除了具备普通监视器所有功能之外，确认监视器还具有状态确认和自动接管两个功能。在数据守护系统的故障自动切换模式下，必须部署一个确认监视器，否则在出现数据库故障时，会导致数据库服务中断。DM 提供了两种确认监视器的配置形式，分别为单实例和多实例。

一个数据守护集群中，最多只能配置一个确认监视器。

当单实例确认监视器故障时，无法继续进行集群的故障自动接管和备库故障确认，影响正常使用，故 DM 提供了多实例确认监控器来进一步提高集群的高可用性。

1.7.1.2.1 单实例

除了具备普通监视器的所有功能之外，单实例确认监视器具有状态确认和自动接管两个功能。相比于多实例确认监视器，单实例确认监视器出现故障就无法正常提供服务。

1.7.1.2.2 多实例

多实例确认监控器提供的功能与单实例确认监控器相同。

多实例确认监视器采用 RAFT 协议实现。在多实例确认监视器中，只有一个实例作为确认监视器提供服务，其它实例作为备库存在而不提供服务。当确认监视器出现故障时，系统会从它的备库中选举一位作为新的确认监视器继续提供服务。

下文将从 RAFT 协议、多实例确认监视器中的各角色状态的作用和特点、多实例确认监视器中选举主监视器三个角度对多实例确认监视器进行详细的介绍。

1.7.1.2.2.1 RAFT 协议简介

RAFT 协议是一种分布式数据一致性算法，通常应用在分布式系统中，用于保证多个服务器之间数据和状态的一致以及故障容错。

一个 RAFT 集群包含多个节点，在任意时刻，每一个服务器节点都处于以下的几种状态之一：Leader、Follower 或 Candidate。通常情况下，系统中有且只有一个 Leader，其它节点都是 Follower。Follower 被动地响应来自 Leader 或 Candidate 的请求；Leader 由选举产生，并负责处理所有来自外部的请求；而 Candidate 则是在选举产生 Leader 的过程中由 Follower 临时切换而来的。

RAFT 协议把从开始选举 Leader，到被选举出的 Leader 失效为止的一段时间称为任期（Term）。我们用连续且递增的整数来标记 Raft 集群中先后产生的每一个任期，这些整数被称为任期号。每一个节点存储一个当前任期号，这一编号随时间单调递增。当服务器之间通信的时候会交换当前任期号；如果一个服务器的当前任期号比其他节点小，那么他会更新自己的编号到较大的编号值。如果一个 Candidate 或者 Leader 发现自己的任期号过期了，那么他会立即恢复成 Follower 状态。如果一个节点接收到一个包含过期的任期号的请求，那么他会直接拒绝这个请求。

1.7.1.2.2.2 角色状态说明

由于多实例确认监视器是基于 RAFT 协议实现的监视器集群，故在任意时刻，多实例确认监视器中的每一个实例节点也处于 Leader、Follower 或 Candidate 的状态之一。

以下是各角色在多实例监视器中的作用和特点的说明：

Leader：主监视器。作为确认监视器向主备集群提供状态确认、自动接管等服务。正常情况下，一个多实例确认监视器集群中最多只存在一个 Leader。在多实例确认监视器的任意节点上执行 show state 命令，可以查看到当前作为 Leader 的节点。

Follower：备监视器。作为 Leader 的备机而存在，不向主备集群提供服务，不允许执行除 show state 之外的监视器命令。

Candidate：候选监视器。Leader 还未选出或者 Leader 异常时，Follower 会主动发起选举选出新 Leader，在发起选举时会切换为此角色。当任一 Candidate 收到监视器集群内大多数节点的选票后，则会切换为 Leader；当任一 Candidate 落选（即其他 Candidate 节点被选为新 Leader）则会切换为 Follower。

Not leader：非主监视器。此状态不属于 RAFT 协议的内容，仅用于 show state 命令中打印显示使用。在无法识别对方是 Follower 还是 Candidate，但可以确定对方不是 Leader 的情况下会将其状态显示为 Not leader。由于在 RAFT 算法之中非 Leader 节点之间的通信较少，大部分情况下两个节点之间只能互相确定对方是否为 Leader；而当对方不是 Leader 时，不能确定对方是 Follower 还是 Candidate。因此，当使用监视器的 show state 命令查看所有节点的状态时，通常会将除 Leader 和自身之外的节点都显示为 Not leader 状态。

1.7.1.2.2.3 选举规则

多实例确认监视器的选举过程完全遵守 RAFT 算法的要求。Leader 会周期性地向其它节点发送心跳信号来维持自己的地位。当某节点超过一定时间没有收到来自 Leader 的消息时，该节点就会发起选举。

每次发起选举时，节点会切换为 Candidate，并将自己的任期号加 1，从而废黜旧 Leader，然后向其余节点发送投票请求。选举过程通过投票完成，每个任期中每个节点有且仅有一张选票，每个节点只会投给与自己相比符合选举要求的节点（有效日志比自己多）；发起选举的节点会直接将票投给自己，其余节点先收到的投票请求先处理，符合要求就会直接投出选票，不会考虑后续收到的投票请求。当发起选举的节点收到超过整个监视器集群节点数一半（包括自己）的选票，就会成为这个新任期的 Leader。

需要注意的是，上述的任期号和日志信息由多实例确认监视器内部进行维护，对于用户是不可见的。因此，对于用户来说，主监视器的选举具有随机性。另外，由于上述规则的限制，需要确保多实例确认监视器中始终有超过半数的节点存活且有效，这样才能正常选举出主监视器作为确认监视器。

二、实时主备

实时主备由主库、实时备库、守护进程和监视器组成。

实时主备系统主要包括以下功能：

实时数据同步

主备库通过实时归档完成数据同步，实时归档要求主库将 RLOG_PKG 发送到备库后，再将 RLOG_PKG 写入本地联机 REDO 日志文件。但要注意的是，备库确认收到主库发送的 REDO 日志，并不保证备库已经完成重演这些 REDO 日志，因此主备库之间的数据同步存在一定的时间差。

主备库切换

主备库正常运行过程中，可以通过监视器的 Switchover 命令，一键完成主备库角色转换。主备库切换功能可以确保在软、硬件升级，或系统维护时，提供不间断的数据库服务。

自动故障处理

备库故障，不影响主库正常提供数据库服务，守护进程自动通知主库修改实时归档为 Invalid 状态，将实时备库失效。

自动数据同步

备库故障恢复后，守护进程自动通知主库发送归档 REDO 日志，重新进行主备库数据同步。并在历史数据同步后，修改主库的实时归档状态为 Valid，恢复实时备库功能。备库接管后，原主库故障恢复，守护进程自动修改原主库的模式为 Standby，并重新作为备库加入主备系统。

备库接管

主库发生故障后，可以通过监视器的 Takeover 命令，将备库切换为主库，继续对外提供服务。如果配置为自动切换模式，确认监视器可以自动检测主库故障，并通知备库接管，这个过程不需要人工干预。

备库强制接管

如果执行 Takeover 命令不成功，但主库可能由于硬件损坏等原因无法马上恢复，为了及时恢复数据库服务，DM 提供了 Takeover Force 命令，强制将备库切换为主库。但需要由用户确认主库故障前，主库与接管备库的数据是一致的（主库到备库的归档是 Valid 状态），避免引发守护进程组分裂。

读写分离访问

在备库查询的实时性要求不高的条件下，实时主备也可以配置接口的读写分离属性访问，实现读写分离功能特性。

三、同步备库

同步备库一般用于对主库性能要求较高，想要避免因备库故障或异步恢复引发的 Suspend 状态切换，但又希望备库的数据延迟不要太大的场合。与实时归档相比，同步归档时机为主库本地归档刷盘之后，主库发送归档到同步备库失败时，不会切换为 Suspend 状态，而是直接将备库的归档状态设置为无效。

同步备库不支持级联配置。Primary 模式的库可以配置最多 8 个同步归档，而 Standby 模式的库只有在配置了实时/即时归档的情况下才允许配置同步归档，这种情况下同样最多可以配置 8 个同步归档。只有 Primary 模式的库会向同步备库发送数据，Standby 模式的库即使配置了同步归档也不会生效。

与异步备库相似，同步备库的守护进程也需要配置为 LOCAL 类型，因此同步备库不支持主备库切换、备库接管等操作。若有将同步备库切换为主库的需要，可以手动执行 sql 语句将其切换为 PRIMARY 模式，但此时数据守护系统并不能保证该操作的正确性，需要由用户自身确认。

配置了 Realtime 和 Timely 归档的主备库，允许配置同一个同步备库。系统自动识别，Primary 模式的库负责向同步备库同步数据，主备库切换后，由新主库负责向同步备库同步数据。这种多源配置的同步备库，可以保证同步备库始终与当前的有效主库保持数据同步。Raft 和 Remote 归档不能与同步归档共存，并且当整个归档配置文件中存在归档目标为 DSC 库的配置项时，也不能再配置同步归档，反之亦然。

配置同步备库十分简单，在 dmarch.ini 中增加同步归档配置，在 dmmal.ini 中增加同步备库的 mal 配置项即可。。同步备库可以不配置本地归档。

四、异步备库

异步备库一般用于历史数据统计、周期报表等对数据实时性要求不高的业务场合。异步归档时机可以选择在源库空闲的时候，可避免源库的业务高峰期同步数据对性能的影响。

每个 Primary 或者 Standby 模式的库都可以配置最多 8 个异步备库。配置了异步备库的 Primary 或者 Standby 模式的库，统称为源库。可以在实时主备、MPP 主备、DMDSC 主备和读写分离集群的主库和备库上配置异步备库，异步备库可级联配置，异步备库本身也可以作为源库配置异步备库。一个监视器最多可以同时监视 16 个异步备库。

配置了 Realtime 和 Timely 归档的主备库，允许配置同一个异步备库，也就是说一个异步备库允许有多个源库。系统自动识别，Primary 模式的源库负责向异步备库同步数据，主备库切换后，由新主库负责向异步备库同步数据。这种多源配置的异步备库，可以保证异步备库始终与当前的有效主库保持数据同步。但是，未配置 Realtime 和 Timely 归档的库，不能配置同一个异步备库。对于级联方式配置的异步备库，也就是异步备库自己作为源库的情况下，仍然需要由用户保证配置的正确性，避免数据同步异常。错误配置多个源库的情况下，多个源库可能同时、或交错向异步备库发送归档日志，导致备库日志连续性校验失败。

异步备库支持延时和定点重演功能，相关使用场景及使用说明请参考 [6.25 异步备库延时和定点重演](https://eco.dameng.com/document/dm/zh-cn/pm/data-guard.html#6.25 异步备库延时和定点重演)。

配置异步备库十分简单，在源库的 dm.ini 中打开定时器 TIMER_INI 开关，同时配置文件 dmtimer.ini，在 dmarch.ini 中增加异步归档配置，在 dmmal.ini 中增加异步备库的 mal 配置，由定时器定时触发源库发送归档日志到异步备库即可。异步备库可以不配置本地归档。

下图中，“源库 P”表示 Primary 模式的库，“源库 S”表示 Standby 模式的库，“源库 S”上允许配置到同一个异步备库的异步归档，但只有“源库 P”会向异步备库同步数据，对于级联方式配置的异步备库，不允许有多个源库。

在这里插入图片描述

2.2.1 数据库

数据守护以库为单位进行管理，一个 DMDSC 集群的所有实例作为一个整体库来考虑。DMDSC 集群的库信息，例如库的状态、模式等需要综合考虑集群内所有实例，同时需要结合 DMDSC 本身的状态。

2.2.2 DMDSC 状态

DMDSC 状态标识 DMDSC 集群节点状态，和数据库的状态不同。包括以下几种：

Startup 节点启动状态，需要通过 DMCSS 工具交互，确定控制节点，执行日志重做等相关步骤，进入到 OPEN 状态。
Open 实例正常工作状态，当集群内发生节点故障或启动节点重加入步骤时，可以进入 crash_recv 或者 err_ep_add 状态，处理完成后会再回到 Open 状态。
Crash_recv 节点故障处理状态。
Err_ep_add 故障节点重加入状态。

2.2.3 数据库模式

DM 支持 3 种数据库模式：Normal 模式、Primary 模式和 Standby 模式。

Normal 模式

提供正常的数据库服务，操作没有限制。正常生成本地归档，但不发送实时归档（Realtime）、即时归档（Timely）和异步归档（Async）。

Primary 模式

提供正常的数据库服务，操作有极少限制。该模式下部分功能受限，包括：不支持修改表空间文件名、不支持修改 arch_ini 参数。正常生成本地归档，支持实时归档（Realtime）、即时归档（Timely）和异步归档（Async）。Primary 模式下，对临时表空间以外的所有的数据库对象的修改操作都强制生成 Redo 日志。

Standby 模式

可以执行数据库备份、查询等只读数据库操作。正常生成本地归档，正常发送异步归档 Redo 日志；但实时归档（Realtime）、即时归档（Timely）均强制失效。该模式下时间触发器、事件触发器等都失效。

可以通过 SQL 语句切换数据库模式，模式切换必须在 Mount 状态下执行。切换模式 SQL 语句如下：

将数据库切换为 Primary 模式：

CopyALTER DATABASE PRIMARY;

将数据库切换为 Standby 模式：

CopyALTER DATABASE STANDBY;

将数据库切换为 Normal 模式：

CopyALTER DATABASE NORMAL;

注意

修改DMDSC库的模式必须在DMDSC库所有实例都处于MOUNT状态下才能进行，只需要在一个节点上执行以上语句即可。

2.2.4 数据库状态

DM 的数据库状态包括：

Startup 状态

系统刚启动时设置为 Startup 状态。

After Redo 状态

系统启动过程中联机日志重做完成后，回滚活动事务前设置为 After Redo 状态。非 Standby 模式的实例在执行 alter database open 操作前，也会将系统设置为 After Redo 状态。

Open 状态

数据库处于正常提供服务的状态，但不能进行归档配置等操作。

Mount 状态

数据库在 Mount 状态下，不能修改数据，不能访问表、视图等数据库对象，但可以执行修改归档配置、控制文件和修改数据库模式等操作，也可以执行一些不修改数据库内容的操作，比如查询动态视图或者一些只读的系统过程。由于 Mount 状态不生成 PWR 日志，因此数据页可以正常刷盘，也正常推进检查点。

系统从 Open 状态切换为 Mount 状态时，会强制回滚所有活动事务，但不会强制清理（Purge）已提交事务，不会强制断开用户连接，也不会强制 Buffer 中的脏页刷盘。

Suspend 状态

数据库在 Suspend 状态下，可以访问数据库对象，甚至可以修改数据，但限制 Redo 日志刷盘，一旦执行 COMMIT 等触发 Redo 日志刷盘的操作时，当前操作将被挂起。

相比 Open 到 Mount 的状态切换，Open 到 Suspend 的状态切换更加简单、高效，不会回滚任何活动事务，在状态切换完成后，所有事务可以继续执行。

一般在修改归档状态之前将系统切换为 Suspend 状态，比如备库故障恢复后，在历史数据（归档日志）同步完成后，需要重新启用实时归档功能时：

将系统切换为 Suspend 状态，限制 Redo 日志写入联机 Redo 日志文件；
修改归档状态为 Valid；
重新将数据库切换为 Open 状态，恢复 Redo 日志写入功能；
备库与主库重新进入实时同步状态。

另外，实时归档失败时（比如网络故障导致），Primary 实例将试图切换成 Suspend 状态，防止后续的日志写入。因为一旦写入，主备切换时有可能备库没有收到最后那次的 RLOG_PKG，导致主库上多一段日志，很容易造成主备数据不一致。当实例成功切换为 SUSPEND 状态时，可直接退出，强制丢弃多余的日志，避免主备数据不一致。

注意

修改DMDSC库的状态为SUSPEND时，库内所有实例都不能处于MOUNT状态，只需要在一个节点上执行ALTER DATABASE SUSPEND语句即可。

Shutdown 状态

实例正常退出时设置为 Shutdown 状态。
在这里插入图片描述

不同数据库状态之间的转换规则如图所示。用户可以通过 SQL 语句进行数据库状态切换：1. Open 状态与 Mount 状态可以相互切换；2. Open 状态与 Suspend 状态可以相互切换；3. Mount 和 Suspend 状态不能直接转换；4. 其他状态为系统内部状态，用户不能主动干预。

注意

对DMDSC集群，除了修改Suspend是同步操作，只需要在一个节点执行外，其他状态修改都需要在每个节点上各自单独执行。

切换数据库状态的 SQL 如下：

1.将数据库修改为 Open 状态。当系统处于 Primary/Standby 模式时，必须强制加上 FORCE 子句。

CopyALTER DATABASE OPEN [FORCE];

将数据库修改为 Mount 状态。

CopyALTER DATABASE MOUNT;

将数据库修改为 Suspend 状态。

CopyALTER DATABASE SUSPEND;

注意

由于dmwatcher根据数据库模式、状态等信息作为故障处理、故障恢复的依据，建议在配置数据守护过程中，修改dm.ini参数ALTER_MODE_STATUS为0，限制用户直接通过SQL语句修改数据库状态、模式以及OGUID，避免dmwatcher做出错误的决策。

2.2.5 LSN 介绍

LSN（Log Sequence Number）是由系统自动维护的 Bigint 类型数值，具有自动递增、全局唯一特性，每一个 LSN 值代表着 DM 系统内部产生的一个物理事务。物理事务（Physical Transaction，简称 ptx）是数据库内部一系列修改物理数据页操作的集合，与数据库管理系统中事务（Transaction）概念相对应，具有原子性、有序性、无法撤销等特性。

DM 数据库中与 LSN 相关的信息，可以通过查询 vrlog和VRAPPLY_PARALLEL_INFO 表来获取。DM 主要包括以下几种类型的 LSN：

● CUR_LSN 是系统已经分配的最大 LSN 值。物理事务提交时，系统会为其分配一个唯一的 LSN 值，大小等于 CUR_LSN + 1，然后再修改 CUR_LSN=CUR_LSN+1。

● FILE_LSN 是已经写入联机 Redo 日志文件的日志包的最大 LSN 值。每次将 Redo 日志包 RLOG_PKG 写入联机 Redo 日志文件后，都要修改 FILE_LSN 值。

● FLUSH_LSN 是已经发起日志刷盘请求，但还没有真正写入联机 Redo 日志文件的最大 LSN 值。

● CKPT_LSN 是检查点 LSN，所有 LSN <= CKPT_LSN 的物理事务修改的数据页，都已经从 Buffer 缓冲区写入磁盘，CKPT_LSN 由检查点线程负责调整。

● APPLY_LSN 是备库已写入联机 Redo 日志文件的日志包的原始最大 LSN 值，此 LSN 取自主库对应的原始日志包中的最大 LSN 值。如果主库是 DMDSC 集群，备库分别为主库每一个节点维护一个 APPLY_LSN。

● RPKG_LSN 是备库重演 LSN，表示备库已经重演完成的最大 LSN。如果主库是 DMDSC 集群，备库分别为主库每一个节点维护一个 RPKG_LSN。

与上述 LSN 对应，DM 数据守护也定义了一批 LSN：

✔CLSN 与 CUR_LSN 保持一致，数据库已经分配的最大 LSN 值。

✔FLSN 与 FILE_LSN 保持一致，已写入联机日志文件的 LSN 值。

✔ALSN 与 APPLY_LSN 保持一致，备库已写入联机日志文件的原始 LSN 值。

✔RLSN 与 RPKG_LSN 保持一致，备库已经重演完成的最大 LSN 值。

✔SLSN 是 Standby LSN 的缩写，表示备库明确可重演的最大 LSN 值。

✔KLSN 是 Keep LSN 的缩写，表示备库已经收到、但未明确是否可以重演的 RLOG_PKG 的最大 LSN 值。在读写分离集群中 KLSN == SLSN。

归档介绍

归档是实现数据守护系统的重要技术手段，根据功能与实现方式的不同，DM 数据库的归档可以分为 6 类：本地归档、远程归档、实时归档、即时归档、异步归档和同步归档。其中，本地归档日志的内容与写入时机与数据库模式相关；主库 Redo 日志写入联机日志文件后，再进行本地归档；备库收到主库产生的 Redo 日志后，直接进行本地归档，同时启动 Redo 日志重演。
在这里插入图片描述