（SERIES5）DM数据库集群介绍

1 数据守护集群

1.1 概述

  DM数据守护（Data Watch）是数据库异地容灾的首选方案。通过DM Data Watch，可以在硬件故障、自然灾害等极端情况下避免数据损坏、丢失，保障数据安全，并可以快速恢复数据库服务，满足用户不间断提供数据库服务的要求。
  相比传统的数据库备份（Backup）和还原（Restore）等手段，需要数小时甚至更长时间恢复数据，数据守护能够在数秒时间内将备库切换为主库对外提供数据服务；
  DM数据守护提供多种解决方案，可以配制成实时主备，且DSC也支持配制成数据守护集群，适用于不同用户需求。

• 实时主备：由一个主库以及一个或多个配置了实时归档的备库组成，主要目的是保障数据库可用性，提高数据安全性；
• DMDSC主备：与单节点主备功能一致，支持DMDSC集群和单节点之间互为主备库，一般建议将DMDSC集群部署为主库，将单节点部署为备库；

什么是重做日志？

• 重做日志即REDO日志，指在DM数据库中添加、删除、修改对象，或者改变数据时，数据库系统都会按照特定的格式，将这些操作执行的结果写入到当前的重做日志文件中；重做日志以log为拓展名，每个DM数据库至少有两个重做日志文件，默认为DAMENG01.log, DMAENG02.log，这两个文件循环使用；
• 重做日志文件因为是数据库正在使用的日志文件，因此也被称为联机日志文件。
• 重做日志主要用于数据库的备份和恢复，例如在遇到硬件故障、系统故障、数据库实例进程被强制终止等，数据库缓冲区中的页文件会来不及写入数据文件；这样，在重启DM数据库实例时，通过重做日志文件中的信息，就可以将数据库的状态恢复到发生意外时的状态。
• 在DM数据库的运行过程中，任何修改数据库的操作都会生成重做日志；重做日志对于数据库是至关重要的，它们用于存储数据库的事务日志。

  在实时主备中，主库提供完整的数据库服务，备库提供只读服务；主库修改数据产生的REDO日志，通过实时归档机制，在写入联机REDO日志文件之前发送到备库，此处的实时备库通过重演REDO日志与主库保持数据同步；当主库出现故障时，备库在将所有REDO日志重演结束后，就可以切换为主库对外提供服务。
  在DMDSC主备中，当DMDSC为主库时，DMDSC集群控制节点收集所有节点的REDO日志发送到备库，备库严格按照各节点修改数据页的先后顺序重演REDO日志保持数据同步；当DMDSC集群为备库时，主库将REDO日志发送至DMDSC集群控制节点，由该节点负责重演REDO日志保持数据同步。

  对上述过程的理解可参考图1-1，会有更加直观的理解。

1.2 数据守护

  数据守护的原理很简单，即将主库（生产库）产生的REDO日志传输到备库，备库接受并重新应用REDO日志，从而实现两者间的数据同步。DM数据守护的核心思想是监控数据库状态，获取主、备库同步情况，为REDO日志传输与重演过程中出现的各种异常情况提供一系列的解决方案。
  DM数据守护系统主要由主库、备库、REDO日志、REDO日志传输、REDO日志重演、守护进程、监视器组成，物理架构如图1-1所示：

图1-1 DM数据守护系统

 
  注意，以下内容将不再着重区分数据库和数据库实例的概念；考虑到数据守护系统中，数据库实例名是唯一的，为了进行更准确的描述，我们会以【实例xxx】来标记每个主库和备库。数据库和数据库实例两者的概念对比有如下：

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

  DM数据守护中的一些概念如下：

1.2.1 主库

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

1.2.2 备库

  备库：Standby模式，提供只读数据库服务的实例，除了容灾还起到备份、查询等只读功能，同时备库还支持临时表的Insert / Delete / Update操作，这一支持主要出于以下两个因素：

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

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

1.2.3 REDO日志

  REDO日志记录物理数据页内容变动情况，是数据守护的实现基础。数据库中Insert / Delete / Update等DML操作与以及CREATE TABLE等DDL操作最终都会体现为对一个或多个物理数据页的修改，因此备库通过重做REDO日志可以与主库保持一致。

1.2.4 REDO日志传输

  主备库之间的REDO日志传输，以日志包RLOG_PKG为单位，主库通过MAL系统发送REDO日志到备库；各种不同数据守护类型之间的区别，就在于主库日志包RLOG_PKG的发送时机，以及备库收到REDO日志后的处理策略。
  官方文档中这样定义MAL系统：MAL系统是DM数据库实例间的高速通信系统，是基于TCP协议实现的一种内部通信机制。可见官方文档 - MAL系统。

1.2.5 REDO日志重演

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

1.2.6 守护进程

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

1.2.7 监视器

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

1.3 数据守护系统特性

• 完整功能主库
• 活动的备库
• 多重数据保护
• 高可用性
• 多种守护模式
• 多种守护类型
• 故障自动重连
• 故障库自动重加入
• 历史数据自动同步
• 自动负载均衡
• 滚动升级
• 灵活的搭建方式
• 完备的监控工具
• 丰富的守护命令
• 支持DMDSC守护

1.4 实时主备

  实时主备系统系统由主库、备库、守护进程和监视器组成。通过部署实时主备系统，可以及时检测并处理各种硬件故障、数据库实例异常，确保持续提供数据库服务。实时主备系统主要包括以下功能：

• 实时数据同步：主备库通过实时归档完成数据同步。实时归档要求主库发送RLOG_PKG到备库后，再将RLOG_PKG写入本地联机REDO日志文件；但要注意的是，备库收到主库发送的REDO日志，并不保证备库已经重演这些REDO日志，因此主备库之间的数据同步存在一定的时间差。
• 主备库切换：主备库正常运行过程中，可以通过监视器的Switchover命令，一键完成主备库角色转换。主备库切换功能可以确保在软、硬件升级，或者系统维护时，提供不间断的数据库服务。
• 自动故障处理：备库故障，不影响主库正常提供数据服务，守护进程自动通知主库修改实时归档为Invalid状态，将实时备库失效。
• 自动数据同步：备库故障恢复后，守护进程自动通知主库发送REDO日志，重新进行主备库数据同步。并在历史数据同步后，修改主库的实时归档状态为Valid，恢复实时备库功能；备库接管后，原主库故障恢复，守护进程自动修改主库的模式为Standby，并重新作为备库加入主备系统（完成了一次主备角色互换）。
• 备库接管：主库发生故障后，可以通过监视器的Takeover命令，将备库切换为主库，继续对外提供服务。如果配置为自动切换模式，确认监视器可以自动检测主库故障，并通知备库接管，过程中不需要人工干预。
• 备库强制接管：如果Takeover命令执行不成功，但主库可能由于硬件损坏等原因无法马上恢复，为了及时恢复数据库服务，DM提供了Takeover Force命令，强制将备库切换为主库；但需要由用户确认主库故障前，主库与接管备库的数据是一致的（主库到备库的归档为Valid状态），避免引发守护进程组分裂。
• 读写分离访问：在备库查询的实时性要求不高的条件下，实时主备也可以配置接口的读写分离访问，实现读写分离功能特性。

1.5 DMDSC数据守护

  DMDSC（数据共享集群）支持多个数据库实例同时访问、修改和保存在共享存储中的数据，能够提供更高的数据库可用性和事务吞吐量；但由于数据是保存在共享存储上，当出现存储失效等故障时，数据库服务将会中断；
  据此，为了提高DMDSC集群的数据安全性、可用性，DM提供了DMDSC集群数据守护功能。DMDSC集群数据守护和单节点数据守护在功能上保持一致，支持故障自动切换、实时归档、读写分离集群、DMDSC的守护；在DMDSC的守护中，又可以分为DMDSC（主）和DMDSC（备）、DMDSC（主）和单节点（备）、单节点（主）和DMDSC（备），这三种搭配相互之间都可以作为主备库的数据守护。
  图1-2中给出DMDSC和单节点互为主备的守护系统结构简图：

图1-2 DMDSC和单节点互为主备的DM Data Watch系统结构图

2 共享存储集群

2.1 DMDSC概述

  DM共享数据库存储集群的英文全称为DM Data Shared Cluster，简称DMDSC。DMDSC允许多个数据库实例同时访问、操作同一数据库，具有高可用、高性能、负载均衡等特性，并支持故障自动切换和故障自动重加入，某一个数据库实例故障后，不会导致数据库服务无法提供。
  DMDSC集群是一个多实例、单数据库的系统；其中，多个实例可以同时访问、修改同一个数据库的数据；用户可以登录集群中的任何一个数据库实例，获得完整的数据库服务。数据文件、控制文件在集群系统中只有一份，不论有几个节点，这些节点都平等地使用这些文件；这些文件保存在共享存储上；各个节点有独立的联机日志和归档日志，这些日志都需要保存在共享存储上。
  DMDSC 集群主要由数据库和数据库实例、共享存储、DMASM 或 DMASM 镜像、本地存储、通信网络、集群控制软件 DMCSS、集群监视器 DMCSSM 组成。DMDSC 集群最多支持 8 个数据库实例节点。
  一个两节点的DMDSC集群结构图如下图2-1所示：

图2-1 一个两节点的DMDSC集群结构

2.2 DMASM

  DMASM（Auto Storage Manager），DM自动存储管理器，是一个专用的分布式文件系统，避免了直接使用块设备作为共享存储来放置数据库文件；DMASM被设计用来管理块设备的磁盘和文件，使用该方案能够帮助用户便捷地管理DMDSC集群的数据文件。其主要部件包括：

• 提供存储服务的块设备
• DMASMSVR管理器
• DMASMAPI接口
• DMASMCMD初始化工具
• DMASMTOOL管理工具

  一个部署了DMASM的DMDSC集群结构图如图2-2所示：

图2-2 一个部署了DMASM的DMDSC结构图

2.3 DMASM镜像

  DMASM镜像提供了多副本和条带化功能。

• 多副本：多副本技术保证同一个数据的多个副本会分别写入到不同的磁盘中；多个副本中只有一个作为主副本对外提供服务，其余副本均作为镜像副本。当主副本发生故障后，系统会从镜像副本中重新自动挑选一个继续提供服务。
• 条带化：条带化技术可保证写入的数据均匀地分配到磁盘组内的不同磁盘中，实现负载均衡。

  DMDSC采用配置镜像功能的DMASM管理的块设备作为共享存储，当出现磁盘损坏 / 数据丢失时，既可以利用其他镜像副本继续提供数据库服务，又可以利用其他镜像副本进行数据恢复。
  一个部署了DMASM镜像的DMDSC集群结构如图2-3所示：

图2-3 一个部署了DMASM镜像的DSC结构

2.4 DMCSS

  DMCSS（Cluster Synchronization Services），DM集群同步服务，是DMASM集群和DMDSC集群的必需配置项。在 DMASM 集群或 DMDSC 集群中，每个节点都需要配置一个 DMCSS 服务，这些 DMCSS 服务自身也构成一个集群；
  DMCSS集群包括控制节点（Control Node）和普通节点（Normal Node）。其中，控制节点负责监控、管理整个DMASM集群和DMDSC集群；普通节点不参与DMASM和DMDSC的管理，而是当控制节点故障时，从活动的普通节点中重新选取一个作为控制节点。
  DMCSS的工作原理是：在VOTE磁盘（非镜像环境下）或DCRV磁盘（镜像环境下），为每个被监控对象（DMASMSVR, DMSERVER, DMCSS）分配一片独立的存储区域；被监控对象定时向 VOTE 或 DCRV 磁盘写入信息（包括时间戳、状态、命令、以及命令执行结果等）；DMCSS 控制节点定时从 VOTE 或 DCRV 磁盘读取信息，检查被监控对象的状态变化，启动相应的处理流程；被监控对象只会被动的接收 DMCSS 控制节点命令，执行并响应。
  DMCSS主要功能包括，写入心跳信息、选举 DMCSS 控制节点、选取 DMASM/DMDSC 控制节点、管理被监控对象的启动流程、集群状态监控、节点故障处理、节点重加入等，DMCSS 还可以接收并执行 DMCSSM 指令。

3 新一代分布式集群

3.1 概述

  DMDPC（Distributed Processing Cluster），达梦分布式计算集群。

3.2 DMDPC系统架构

  一个完整的 DMDPC 架构由计划生成节点 SP（SQL Processor）、数据存储节点 BP（Backend Processor） 和元数据服务器节点 MP（Metadata Processor） 三部分组成。

• SP 对外提供分布式数据库服务，用户可以登录到任意一个 SP 节点，获得完整的数据库服务；
• BP 负责存储数据，执行 SP 的调度指令并将执行结果返回给 SP；
• MP 负责存储元数据并向 SP、BP 提供元数据服务。

  SP 节点不存储数据，配置成单机即可；MP 和 BP 节点既可以配置成单机，也可以配置成多副本系统。其中每一个多副本系统中只有一个作为主节点，其余节点均作为备份节点。有一个典型的配备了多副本系统的DMDPC架构图如图3-1所示：

图3-1 配置了多副本系统的DMDPC架构图

3.2.1 SP（SQL Processor）

  SP在集群中负责对外提供服务，接收用户请求并生成计划、划分子计划、按照一定规则计算并行度并调度子计划，最终返回直接结果给用户；SP是在单机数据库上新增分布式特性改进而来的。

3.2.2 BP（Backend Processor）

  BP是DMDPC中实际存储数据的节点，负责存储数据，接收、执行SP的子任务调度指令并返回任务结果。
  一个DMDPC可配置【多个】BP节点同时提供服务，并根据业务量变化随时调整；为保证BP节点能够提供不间断服务，可以将每个BP节点配制成一个多副本系统。

3.2.3 MP（Metadata Processor）

  元数据节点，在DMDPC中提供元数据服务（字典信息服务）。所有DDL / DML请求发送到SP后被识别，若是DDL请求，则转发到MP执行，元数据信息都存储在MP。
  一个DMDPC只能配置一个MP节点提供服务。为了保证MP节点能持续提供服务，可以将MP节点配制成一个多副本系统。

3.2.4 DM多副本系统

  DM多副本系统由N个节点实例组成，N必须是大于1的奇数；只有配置了RAFT归档的实例才能加入多副本系统；
  同一个RAFT组中的所有节点（3个或3个以上）共同构成一个多副本系统，一个多副本系统最多支持9个节点实例；实例之间采用XMAL模块进行TCP协议通讯；各个节点实例之间基于RAFT协议选出一个主库，其余作为备库；主库会向备库同步日志，备库负责接收并重新应用日志，从而使主备之间数据一致。
  BP的多副本架构如图3-2所示：

图3-2 BP多副本架构

 
  上图3-2中展示了三个BP域的集群架构，每个BP域中都包含多个BP。同一个RAFT组中的多个BP保存了同样数据的多个副本，即BP1, BP2和BP3中存储的内容完全相同，同一个RAFT组中的所有BP节点共同构成一个BP多副本系统；多副本系统中一个为主节点对外提供服务；其余为备份节点，当主节点故障时可顶替执行主节点任务。
  在 BP 多副本系统中，可通过 V​ARCH_STATUS 和 VRLOG_RAFT_INFO 来查看整个系统中主备环境的运行状况。

  MP的多副本架构如图3-3所示：

图3-3 MP多副本架构

 
  上图中展示了三个MP域的集群架构，每个MP域中最多只包含一个MP。集群的其他配置与BP相同；同样可以使用VARCH_STATUS和VRLOG_RAFT_INFO来查看整个系统中主备环境的运行状况。

3.3 DMDPC系统特性

• 高可用：适应分布式集群两地三中心的部署需求；
• 高可扩展：自动伸缩；
• 高性能：DMDPC对OLAP和OLTP型场景都很适用。
• • OLAP（Online Analytical Processing，在线分析处理），主要特点包括复杂查询、多维数据分析、读操作为主、数据整合、长响应时间等；典型应用场景包括商业智能（BI）、数据仓库、报告和仪表盘等；
• • OLTP（Online Transaction Processing，在线事务处理），主要特点包括高并发、实时处理、数据一致性、写操作为主、标准化数据结构等；典型应用场景包括电子商务、银行交易、客户关系管理（CRM）、票务系统等。
• 高吞吐量：DMDPC 集群中，多个 BP 节点可以充分利用多台物理主机的处理能力，支撑更多的用户连接请求，提供更高的吞吐量；DMDPC 集群中包含多个 BP 数据库实例，BP 数据库实例访问独立的处理器、内存。
• 透明性

  社区地址：https://eco.dameng.com