DM8共享存储集群（DMDSC）

概述

DMDSC 集群是一个多实例、单数据库的系统。多个数据库实例可以同时访问、修改同一个数据库的数据。用户可以登录集群中的任意一个数据库实例，获得完整的数据库服务。数据文件、控制文件在集群系统中只有一份，不论有几个节点，这些节点都平等地使用这些文件，这些文件保存在共享存储上。每个节点有自己独立的联机日志和归档日志，其中联机日志保存在共享存储上，归档日志可以保存在本地存储上也可以保存在共享存储上。

DMDSC 集群主要由数据库和数据库实例、共享存储、DMASM 或 DMASM 镜像、本地存储、通信网络、集群控制软件 DMCSS、集群监视器 DMCSSM 组成。下图展示了一个 DMDSC 集群系统结构图。

图1.1 一个DMDSC集群结构图

系统特性

DMDSC 的主要特点包括：

1. 高可用性 只要集群中有一个活动节点，就能正常提供数据库服务。此外，当出现磁盘损坏或数据丢失时，既可以利用其他镜像副本继续提供数据库服务，又可以使用其他镜像副本进行数据恢复。
2. 高吞吐量 多个节点同时提供数据库服务，有效提升集群的整体事务处理能力。
3. 负载均衡 一方面，通过巧用服务名，用户的连接请求被平均分配到集群中的各个节点，确保连接负载平衡；另一方面，条带化技术可保证写入的数据均匀分布到磁盘组内的不同磁盘中，实现数据负载均衡。

高可用性

DMDSC 集群通过两种方式提供达梦数据库高可用解决方案。

一、使用集群控制软件 DMCSS

当出现系统故障、硬件故障、或人为操作失误时，DMCSS 可检测故障并自动将故障节点踢出集群，保证数据库服务的正常提供。

故障节点的用户连接会自动切换到活动节点，这些连接上的未提交事务将被回滚，已提交事务不受影响；活动节点的用户连接不受影响，正在执行的操作将被挂起一段时间，在故障处理完成后，继续执行。当 DMCSS 检测到故障节点恢复时，自动启动节点重加入流程，将恢复的故障节点重新加入 DMDSC 集群，将集群恢复到正常的运行状态。因此，通过部署 DMDSC 集群，可以在一定程度上避免由软、硬件故障引起的非计划停机，减少这些意外给客户带来的损失。

与同样使用共享存储的双机热备系统相比，DMDSC 具有更快的故障处理速度。双机热备系统故障切换时，需要完整地重做 REDO 日志，所有数据均需重新从磁盘加载；而 DMDSC 故障处理时（由 INI 参数 DSC_CRASH_RECV_POLICY 控制），只要重做故障节点的 REDO 日志，并且大部分数据页已经包含在处理节点的 Buffer 缓冲区中，不需要重新从磁盘加载。

二、使用 DMASM 镜像的多副本技术

如果 DMDSC 配置了 DMASM 镜像，镜像功能可提供多副本技术。当出现磁盘损坏或数据丢失时，系统无需人工干预即可利用其他镜像副本继续提供数据库服务，同时又可以自动或手动通过使用其他镜像副本进行数据恢复。

高吞吐量

DMDSC 集群中包含多个数据库实例，数据库实例访问独立的处理器、内存，数据库实例之间通过缓存交换技术提升共享数据的访问速度，每个数据库实例都可以接收并处理用户的各种数据库请求。

与单节点数据库管理系统相比，DMDSC 集群可以充分利用多台物理机器的处理能力，支撑更多的用户连接请求，提供更高的吞吐量。与双机热备系统相比，DMDSC 集群不存在始终保持备用状态的节点，不会造成硬件资源的浪费。

负载均衡

DMDSC 从连接和数据两个层面提供负载均衡特性。

一、通过巧用服务名

通过配置 DM 数据库连接服务名来访问 DMDSC 集群，可以实现节点间的连接自动负载均衡。用户的数据库连接请求会被自动、平均地分配到 DMDSC 集群中的各个节点。并且连接服务名支持 JDBC、DPI、ODBC、DCI、.Net Provider 等各种数据库接口。

二、使用镜像的条带化技术

通过配置 DMASM 镜像，使用镜像的条带化技术可保证写入的数据均匀分布到磁盘组内的不同磁盘中，实现数据负载均衡。

基本概念

数据库和数据库实例

数据库（Database）是一个文件集合（包括数据文件、临时文件、重做日志文件和控制文件等），保存在物理磁盘或文件系统中。

数据库实例（Dmserver）就是一组操作系统进程（或一个多线程的进程）以及一些内存。通过数据库实例，可以操作数据库，一般情况下，我们访问、修改数据库都是通过数据库实例来完成的。

共享存储

DMDSC 集群中，为了实现多个实例同时访问、修改数据，要求将数据文件、控制文件、日志文件保存在共享存储上。

DMDSC 使用 DMASM 文件系统管理共享存储设备。DMASM 有两个版本：一是早期版本，提供基础的磁盘组操作、文件操作等，详细用法请参考[10 DMASM 介绍](#10 DMASM 介绍)；二是 ASM 镜像版本，在早期版本的基础上增加了 ASM 文件镜像功能、文件条带化功能、DCRV 多磁盘功能等，详细用法请参考[11 DMASM 镜像介绍](#11 DMASM 镜像介绍)。两种版本的 ASM 文件互不兼容。

本地归档日志既可以保存在普通磁盘上也可以保存在共享存储上。如果保存在共享存储上会占用较为宝贵的共享存储资源，因此建议放在普通磁盘上即可。

一台共享存储上，只能搭建一套 DMASM 文件系统，多套会导致系统启动失败。

本地存储

DMDSC 集群中，本地存储用来保存配置文件（记录数据库实例配置信息的 DM.INI、DMARCH.INI、DMMAL.INI），本地归档日志、远程归档日志。

通信网络

DMDSC 集群中，网络分为对外服务网络、MAL 高速内网和高速共享存储网络三部分。

对外服务网络用于对外提供数据库服务，用户使用公共网络地址登录 DMDSC 集群，访问数据库。

MAL 高速内网用于数据库实例之间交换信息和数据。MAL 链路即为 MAL 高速内网。

高速共享存储网络用于数据库实例和共享存储之间的通信。常见的两种方式为通过光纤通道实现或通过网络 SCSI 实现。高速共享存储网络搭建工作一般由存储设备厂商完成，不是本书讨论的内容，具体实施方案请咨询共享存储设备厂商或达梦 DBA。

集群和集群组

集群（Cluster）是由两个或多个节点（服务器）构成的一种松散耦合的计算机节点集合，这个集合在整个网络中表现为一个单一的系统，并通过单一接口进行使用和管理。大多数模式下，集群中的所有计算机都拥有一个相同的名称，集群内任意一个系统都可以被所有的网络用户使用。每个集群节点都是运行其自己进程的独立服务器，因此每个节点都有自己的运算能力。这些进程间彼此通信进行协调，协同起来向用户提供应用程序、系统资源和数据以及计算能力。

本文档中涉及到的集群有三种：DMDSC 集群，DMCSS 集群和 DMASM 集群。一个 DMDSC 集群由多个 DMSERVER 服务器共同构成；一个 DMCSS 集群由多个 DMCSS 服务器共同构成；一个 DMASM 集群由多个 DMASM 服务器共同构成。

集群又称为集群组。集群组的概念在配置 DMDCR_CFG.INI 文件中使用，用于配置一个集群中的组内成员节点的公用和专用信息。DMDSC 集群，DMCSS 集群和 DMASM 集群的集群组类型分别为 DB、CSS 和 ASM。例如：一个 DMDSC 集群中共含有 5 个 DMSERVER 节点，则在 DMDCR_CFG.INI 中，该 DMDSC 集群的组类型为 DB，组中成员的个数为 5。

DMDSC 集群

DMDSC 集群由若干数据库实例组成，这些实例间通过网络（MAL 链路）连接，通过一个特殊的软件（DMCSS，集群同步服务）的协助，共同操作一个数据库。从外部用户视角来看，他们看到的只是一个数据库。数据文件、控制文件等文件在集群中只有一份，所有节点平等地使用这些数据文件。这份数据存放在共享存储上，每个服务器通过高速共享存储网络连接到共享存储上。

DM 自动存储管理器

DM 自动存储管理器（DM Auto Storage Manager，简称 DMASM）是一个专用用来为块设备管理文件的分布式文件系统。使用 DMASM 文件系统可以灵活地在块设备上创建、删除、扩展、截断文件，不用担心空间不足（可以通过在线增加块设备的磁盘来扩展空间）或空间浪费；不用考虑文件个数限制；可以方便地查看空间使用情况。

DMDSC 支持多个节点同时访问、修改 DMASM 中的数据文件。

DMASM 不是一个通用的文件系统，应用程序只能通过 DMASMAPI 接口访问。理论上通过 DMASMAPI 接口可以存放任何文件，但在 DMDSC 集群中，一般只建议将需要在节点间共享访问的文件存在 DMASM 中，如数据文件、联机 REDO 日志文件、控制文件等。归档 REDO 日志文件、备份集文件也可以考虑保存到 DMASM 中，避免还原、恢复等操作时节点间的文件拷贝，简化备份、还原操作。其他的一些本地配置文件比如 DM.INI 等建议保存在本地磁盘中。

DMDSC 集群中若配置 DMASM，则要求 DMASM 站点数和 DMCSS 站点数一致，且只能存在一个 DMCSS 组和一个 DMASM 组。

DM 集群同步服务

DM 集群同步服务（DM Cluster Synchronization Services，简称 DMCSS）是一款集群控制软件，是 DMDSC 集群应用的基础。DMCSS 专门负责监控集群中各个节点的运行状态，主要功能包括集群环境中节点的启动、故障处理、节点重加入等操作。

每个 DMDSC 集群或 DMASM 集群节点都必须配置一个 DMCSS 服务。这些 DMCSS 服务又共同构成一个 DMCSS 集群。单节点应用时，可以不配置 DMCSS。

DM 集群监视器

DM 集群监视器（DM Cluster Synchronization Services Monitor，简称 DMCSSM）用来监控整个集群的状态信息。

DMCSSM 与 DMCSS 相互通信，从 DMCSS 处获取整个集群系统的状态信息。DMCSSM 提供一系列管理维护集群的命令。

配置了 DMCSS 的集群中，可配置 0~10 个 DMCSSM。为了防止硬件损坏导致 DMCSSM 和其他服务器同时故障，建议用户将 DMCSSM 和其他服务器分开放置，DMCSSM 可单独放置在一台机器上。

心跳机制

DMCSS 的心跳机制（Heartbeat）是通过 VOTE 磁盘（非镜像环境下）或 DCRV 磁盘（镜像环境下）的 Disk Heartbeat 实现。更多关于 VOTE 磁盘的介绍请参考[10 DMASM 介绍](#10 DMASM 介绍)。更多关于 DCRV 磁盘的介绍请参考[11 DMASM 镜像介绍](#11 DMASM 镜像介绍)。

心跳机制有最大时延，只有超过最大时延，才认为监测对象故障。

MAL 链路

MAL 系统是达梦数据库基于 TCP 协议实现的一种内部通信机制，具有可靠、灵活、高效的特性。使用 DMASM 文件系统的 DMDSC 集群中存在两套 MAL 系统，DMASM 服务器之间配置一套 MAL 系统，DMSERVER 服务器之间配置一套 MAL 系统。两套 MAL 系统工作原理相同：一旦 MAL 链路出现异常，DMCSS 会进行裁定，并从集群中踢出一个节点，保证集群环境正常运行。

共享内存

共享内存是一种快速、高效的进程间通信手段。所谓共享内存，就是同一块物理内存被映射到多个进程的地址空间，进程 A 可以即时看到进程 B 对共享内存的修改，反之亦然。DMASM 服务器进程和 DMASM 客户端进程之间通过共享内存方式共享 ASM 文件到实际磁盘的映射关系。

关键技术

DMDSC 是一个共享存储的数据库集群系统。多个数据库实例同时访问、修改同一个数据库，必然会带来全局并发问题。DMDSC 集群基于 DM 单节点数据库管理系统，改造了 Buffer 缓冲区、事务系统、封锁系统和日志系统等，以适应共享存储集群节点间的全局并发访问控制要求。同时，引入缓存交换技术，提升数据在节点间的传递效率。

事务管理

多版本并发控制（MVCC）可以确保数据库的读操作与写操作不会相互阻塞，大幅度提升数据库的并发度以及使用体验，大多数主流商用数据库管理系统都实现了 MVCC。DM 的多版本并发控制实现策略是：数据页中只保留物理记录的最新版本数据，通过回滚记录维护数据的历史版本，通过活动事务视图（V$TR{X}_{V}IEW和V$DSC_TRX_VIEW）判断事务可见性，确定获取哪一个版本的数据。

每一条物理记录中包含了两个字段：TID 和 RPTR。TID 保存修改记录的事务号，RPTR 保存回滚段中上一个版本回滚记录的物理地址。插入、删除和更新物理记录时，RPTR 指向操作生成的回滚记录的物理地址。

回滚记录与物理记录一样，也包含了 TID 和 RPTR 这两个字段。TID 保存产生回滚记录时物理记录上的 TID 值（也就是上一个版本的事务号），RPTR 保存回滚段中上一个版本回滚记录的物理地址。

每一条记录（物理记录或回滚记录）代表一个版本。如下图所示：

图 2.1 各版本之间的关系

如何找到对当前事务可见的特定版本数据，进行可见性判断，是 DM 实现多版本并发控制的关键。根据事务隔离级别的不同，在事务启动时（串行化），或者语句执行时（读提交），收集这一时刻所有活动事务，并记录系统中即将产生的事务号 NEXT_TID。DM 多版本并发控制可见性原则：

1. 物理记录 TID 等于当前事务号，说明是本事务修改的物理记录，物理记录可见
2. 物理记录 TID 不在活动事务表中，并且 TID 小于 NEXT_TID，物理记录可见
3. 物理记录的 TID 包含在活动事务表中，或者 TID>=NEXT_TID，物理记录不可见

为了在 DMDSC 集群中实现与单节点相同的多版本并发控制（MVCC）策略，每个事务需要知道所有节点当前活动的事务信息，根据事务隔离级的不同，在事务启动时（串行化），或者语句执行时（读提交），收集这一时刻所有节点上的活动事务，以及系统中即将产生的事务号 NEXT_TID，记录到事务的活动事务视图中。DMDSC 集群将事务信息全局化，由控制节点统一管理集群中所有节点的全局事务视图（Global Transaction View，简称 GTV）；与之对应的是每个节点维护一个本地事务视图（Local Transaction View，简称 LTV），在事务启动、收集活动事务信息时通知全局事务视图，并获取相应的信息。

封锁管理

数据库管理系统一般采用行锁进行并发访问控制，避免多个用户同时修改相同数据；通过表锁、字典锁控制 DDL 和 DML 操作的并发访问，保证对象定义的有效性和数据访问的正确性。DM 则采用了独特的封锁机制，使用 TID 锁和对象锁进行并发访问控制，有效减少封锁冲突、提升系统并发性能。

TID 锁以事务号为封锁对象，每个事务启动时，自动以独占（X）方式对当前事务号进行封锁，由于事务号是全局唯一的，因此这把 TID 锁不存在冲突，总是可以封锁成功。同时，在 4.1 事务管理中，介绍了物理记录上包含一个 TID 字段，记录了修改数据的事务号。执行 INSERT、DELETE、UPDATE 操作修改物理记录时，设置事务号到 TID 字段的动作，就相当于隐式地对物理记录上了一把 X 方式的 TID 锁。因此，通过事务启动时创建的 TID 锁，以及写入物理记录的 TID 值，DM 中所有修改物理记录的操作都不再需要额外的行锁，避免了大量行锁对系统资源的消耗，有效减少封锁冲突。特别是在 DMDSC 集群中，需要进行全局封锁，封锁的代价比单节点更高，通过 TID 锁可以有效减少封锁引发的性能损失。

对象锁则通过对象 ID 进行封锁，将对数据字典的封锁和表锁合并为对象锁，以达到减少封锁冲突、提升系统并发性能的目的。

与事务管理类似，DMDSC 集群将封锁管理拆分为全局封锁服务（Global Locking Services，简称 GLS）和本地封锁服务（Local Locking Services，简称 LLS）两部分。整个系统中，只有控制节点拥有一个 GLS。控制节点的 GLS 统一处理集群中所有节点的封锁请求、维护全局封锁信息、进行死锁检测，确保事务并发访问的正确性。每个节点都有一个 LLS。各节点的 LLS 负责与 GLS 协调、通讯，完成事务的封锁请求，DMDSC 集群中所有封锁请求都需要通过 LLS 向 GLS 发起，并在获得 GLS 授权后，才能进行后续操作。

闩管理

闩（Latch）是数据库管理系统的一种内部数据结构，通常用来协调、管理 Buffer 缓冲区、字典缓存和数据库文件等资源的并发访问。与锁（Lock）在事务生命周期中一直保持不同，闩（Latch）通常只保持极短的一段时间，比如修改 Buffer 中数据页内容后，马上会释放。闩（Latch）的封锁类型也比较简单，就是共享（Share）和独占（Exclusive）两种类型。

为了适用 DMDSC 集群，我们同样将闩划分为全局闩服务（Global Latch Services，简称 GLS）和本地闩服务（Local Latch Services，简称 LLS）两个部分。但是，为了与全局封锁服务 GLS 和本地封锁服务 LLS 的名字简称区分开来，我们以使用最为频繁的 Buffer 来命名全局闩服务。因此，全局闩服务也称为全局缓冲区服务（Global Buffer Services），简称 GBS；本地闩服务也称为本地缓冲区服务（Local Buffer Services），简称 LBS。

整个系统中，每一个节点上都部署一个 GBS 和一个 LBS。GBS 服务协调节点间的 Latch 封锁请求、以及 Latch 权限回收。GBS 与 GTV/GLS 由控制节点统一管理不同，GBS 不是集中式管理，而是由 DMDSC 集群中的所有节点共同管理，Buffer 对象会根据数据页号（Page No）对数据页进行划分，分给某一个节点的 GBS 服务处理。LBS 服务与 LLS/LTV 一样，部署在每一个节点，LBS 服务根据用户请求，向 GBS 发起 Latch 封锁，或者根据 GBS 请求，回收本地的 Latch 封锁。

为了避免两个或多个节点同时修改同一个数据页导致数据损坏，或者数据页修改过程中别的节点读取到无效内容，DMDSC 集群中数据页的封锁流程做了一些改变。与单节点相比，增加了全局 Latch 封锁、释放两个步骤。同时在获取全局 Latch 授权后，仍然需要进行正常的本地 Latch 封锁，有效避免了节点内的访问冲突。

缓存交换

根据目前的硬件发展状况来看，网络的传输速度比磁盘的读、写速度更快，因此，DMDSC 集群引入了缓存交换（Buffer Swap）技术，节点间的数据页尽可能通过网络传递，避免通过磁盘的写入、再读出方式在节点间传递数据，从而减少数据库的 IO 等待时间，提升系统的响应速度。

缓存交换的实现基础是 GBS/LBS 服务，在 GBS/LBS 中维护了 Buffer 数据页的相关信息。包括：1. 闩的封锁权限（LATCH）；2. 哪些站点访问过此数据页（Access MAP）；3. 最新数据保存在哪一个节点（Fresh EP）中；4. 以及最新数据页的 LSN 值（Fresh LSN）等信息。这些信息作为 LBS 封锁、GBS 授权和 GBS 权限回收请求的附加信息进行传递，因此并不会带来额外的通讯开销。

下面以两节点 DMDSC 集群（EP0/EP1）访问数据页 P1 为例子。初始页 P1 位于共享存储上，P1 的 GBS 控制结构位于节点 EP1 上。初始页 P1 还没有被任何一个节点访问过，初始页 P1 的 LSN 为 10000。通过几种常见场景分析，逐步深入，解析缓存交换的原理。

场景 1
节点 EP0 访问数据页 P1。

1. 节点 EP0 的本地 LBS 向 EP1 的 GBS 请求数据页 P1 的 S LATCH 权限
2. 节点 EP1 的 GBS 修改 P1 控制结构，记录访问节点 EP0 的封锁模式为 S LATCH（数据分布节点为 EP0），并响应 EP0 的 LBS 请求
3. 节点 EP0 的 LBS 获得 GBS 授权后，记录获得的授权模式是 S_LATCH，P1 数据不在其他节点的 Buffer 中，发起本地 IO 请求，从磁盘读取数据。IO 完成后，修改 LBS 控制结构，记录数据页上的 LSN 信息

图2.2 本地IO

场景 2
节点 EP1 访问数据页 P1。

1. 节点 EP1 本地 LBS 向 EP1 的 GBS 请求数据页 P1 的 S LATCH 权限
2. 节点 EP1 的 GBS 修改控制结构，记录访问节点 EP1 的封锁模式为 S LATCH（数据分布节点为 EP0/EP1），并响应 EP1 的 LBS 请求
3. 节点 EP1 的 LBS 获得 GBS 授权后，记录获得的授权模式是 S LATCH，根据数据分布情况，EP1 向 EP0 发起 P1 的读请求，通过内部网络从 EP0 获取数据，而不是重新从磁盘读取 P1 数据
   

图2.3 远程IO

场景 3
节点 EP0 修改数据页 P1。

1. 节点 EP0 本地 LBS 向 EP1 的 GBS 请求数据页 P1 的 X LATCH 权限（附加 LSN 信息）
2. 节点 EP1 的 GBS 修改控制结构的 LSN 值，从 EP1 的 LBS 回收 P1 的权限
3. 修改访问节点 EP0 的封锁模式为 S + X LATCH，并响应 EP0 的 LBS 请求
4. 节点 EP0 的 LBS 获得 GBS 授权后，记录获得的授权模式是 S + X LATCH
5. 节点 EP0 修改数据页 P1，LSN 修改为 11000
   这个过程中，只有全局 Latch 请求，数据页并没有在节点间传递。
   

图2.4 GBS管理

修改之后，数据页 P1 的 LSN 修改为 11000。如下所示：

图2.5 数据修改

场景 4
节点 EP1 修改数据页 P1。

1. 节点 EP1 本地 LBS 向 EP1 的 GBS 请求数据页 P1 的 X LATCH 权限

2. 节点 EP1 的 GBS 发现 P1 被 EP0 以 S + X 方式封锁，向 EP0 发起回收 P1 权限的请求

3. 节点 EP0 释放 P1 的全局 LATCH，响应 GBS，并且在响应消息中附加了最新的 PAGE LSN 值

4. 节点 EP1 的 GBS 收到 EP0 的响应后，修改 GBS 控制结构，记录最新数据保存在 EP0，最新的 LSN 值信息，记录 EP1 获得的授权模式是 S + X LATCH（此时，数据分布节点仍然是 EP0/EP1），并授权 EP1 的 LBS

5. 节点 EP1 的 LBS 收到授权信息后，记录获得的授权模式是 S + X LATCH，并根据数据分布情况，向节点 EP0 发起数据页 P1 的读请求

6. 节点 EP1 修改数据页 P1，LSN 修改为 12000
   

图2.6 GBS管理

修改之后，数据页 P1 的 LSN 修改为 12000。如下所示：

图2.7 数据修改

这个过程中，数据页 P1 的最新数据从 EP0 传递到了 EP1，但并没有产生磁盘 IO。

重做日志管理

REDO 日志包含了所有物理数据页的修改内容，Insert/delete/update 等 DML 操作、Create Table 等 DDL 操作，最终都会转化为对物理数据页的修改，这些修改都会反映到 REDO 日志中。一般说来，一条 SQL 语句在系统内部会转化为多个相互独立的物理事务来完成，物理事务提交时产生 REDO 日志，并最终写入联机 REDO 日志文件中。

一个物理事务包含一个或者多个 REDO 记录（Redo Record，简称 RREC），每条 REDO 记录都对应一个修改物理数据页的动作。根据记录内容的不同，RREC 可以分为两类：物理 RREC 和逻辑 RREC。物理 RREC 记录的是数据页的变化情况，内容包括：操作类型、修改数据页地址、页内偏移、数据页上的修改内容、长度信息（变长类型的 REDO 记录才有）。逻辑 RREC 记录的是一些数据库逻辑操作步骤，主要包括：事务启动、事务提交、事务回滚、字典封锁、事务封锁、B 树封锁、字典淘汰等，一般只在配置为 Primary 模式时才产生逻辑 RREC。

图 2.8 PTX 和 RREC 结构图

DMDSC 集群中，各个节点拥有独立的日志文件，Redo 日志的 LSN 值也是顺序递增的，Redo 日志只会写入当前数据库实例的联机日志文件，与集群系统中的其他数据库实例没有关系。考虑到所有节点都可以修改数据，同一个数据页可能由不同节点先后修改，为了体现修改的先后顺序，确保故障恢复时能够按照操作的顺序将数据正确恢复。DMDSC 集群要求对同一个数据页的修改，产生的 LSN 值是全局递增的，各个节点对同一数据页的修改在日志系统中是严格有序的。但是，针对不同数据页的修改并不要求 LSN 是全局递增的，也就是说只有多个节点修改相同数据页时，才会产生全局 LSN 同步问题。并且 LSN 全局同步，是在缓存交换时附带完成的，并不会增加系统的额外开销。

与单节点系统相比，DMDSC 的日志系统存在以下差异：

1. 本地 REDO 日志系统中，LSN 值保证是递增的，后提交物理事务的 LSN 值一定更大；但顺序提交的两个物理事务产生的 LSN 值，不能保证一定是连续的。

2. 全局 REDO 日志系统中，LSN 值不再严格保证唯一性。不同节点可能存在 LSN 值相等的重做日志记录。

3. 故障重启时，控制节点需要重做所有节点的 REDO 日志，重做过程中会根据 LSN 排序，从小到大依次重做。

4. 联机 REDO 日志文件需要保存在共享存储中。

回滚记录管理

DMDSC 集群的多版本并发控制（MVCC）实现策略是，通过回滚记录获取数据的历史版本，通过活动事务视图判断事务可见性、确定获取指定版本数据。因此，回滚记录也必须进行全局维护，有可能在节点间进行传递。与单节点一样，DMDSC 集群中只有一个回滚表空间，回滚记录保存在回滚页中，回滚页与保存用户记录的数据页一样，由 Buffer 系统管理，并通过缓存交换机制实现全局数据共享。

为了减少并发冲突，提高系统性能，DMDSC 集群中为每个节点分配了一个单独的回滚段（Segment），虽然这些回滚段位于同一个回滚表空间中，但是各个节点的回滚页申请、释放，并不会产生全局冲突。

与重做日志一样，DMDSC 集群故障重启时，控制节点会扫描所有节点的回滚段，收集未提交事务进行回滚，收集已提交事务进行 Purge 操作。

达梦数据库 | 达梦在线服务平台