数据守护与读写分离集群介绍

数据守护与读写分离集群介绍

DM 数据守护 (Data Watch)

Data Watch 简介

DM 数据守护 (Data Watch) 是一种集成化的高可用、高性能数据库解决方案，是数据库异地容灾的首选方案。通过部署 DM 数据守护，可以在硬件故障（如磁盘损坏）、自然灾害（地震、火灾）等极端情况下，避免数据损坏、丢失，保障数据安全，并且可以快速恢复数据库服务，满足用户不间断提供数据库服务的要求。与常规的数据库备份 (Backup)、还原 (Restore) 技术相比，数据守护可以更快地恢复数据库服务。随着数据规模不断增长，通过还原手段恢复数据，往往需要数个小时、甚至更长时间，而数据守护基本不受数据规模的影响，只需数秒时间就可以将备库切换为主库对外提供数据库服务。

DM 数据守护提供多种解决方案，可以配置成实时主备、MPP 主备或读写分离集群，满足用户关于系统可用性、数据安全性、性能等方面的综合需求，有效降低总体投入，获得超值的投资回报。

实时主备由一个主库以及一个或者多个配置了实时 (Realtime) 归档的备库组成，其主要目的是保障数据库可用性，提高数据安全性。实时主备系统中，主库提供完整的数据库功能，备库提供只读服务。主库修改数据产生的 Redo 日志，通过实时归档机制，在写入联机 Redo 日志文件之前发送到备库，实时备库通过重演 Redo 日志与主库保持数据同步。当主库出现故障时，备库在将所有 Redo 日志重演结束后，就可以切换为主库对外提供数据库服务。

MPP 主备就是在 MPP 集群的基础上，为每一个 MPP 节点配置一套实时主备系统，这些实时主备系统一起构成了 MPP 主备系统。我们将一个 MPP 节点对应的主备系统称为一个数据守护组 (Group)，MPP 主备系统中各个数据守护组保持相对独立，当某个 MPP 主节点出现故障时，在其对应的数据守护组内挑选一个备库切换为主库后，就可以确保整个 MPP 集群的正常使用。

读写分离集群由一个主库以及一个或者多个配置了即时 (Timely) 归档或实时 (Realtime) 归档的备库组成，其主要目标是在保障数据库可用性基础上，实现读、写操作的自动分离，进一步提升数据库的业务支撑能力。读写分离集群通过配置事务一致模式保证主、备库数据一致性，并配合 DM 数据库管理系统的各种接口（JDBC、DPI 等），将只读操作自动分流到备库，有效降低主库的负载，提升系统吞吐量。

Data Watch 结构

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

DM 数据守护系统结构参考图如下所示：

DM 数据守护系统主要由：主库、备库、Redo 日志、Redo 日志传输、Redo 日志重演、守护进程 (dmwatcher)、监视器 (dmmonitor) 组成。

数据库与数据库实例

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

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

本文档将不再严格区分数据库和数据库实例的概念，很多地方会笼统的以库来代替。考虑到数据守护系统中，数据库实例名是唯一的，为了更准确地进行描述，很多情况下我们会以实例 xxx来标记某一个主库或者备库。

主库

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

备库

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

备库支持临时表修改主要基于两个因素：

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

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

Redo 日志

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

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

Redo 日志传输

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

Redo 日志重演

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

守护进程

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

监视器

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

Data Watch 系统特性

DM 数据守护 (Data Watch) 的主要特性包括：

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

DM 实时主备

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

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

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

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

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

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

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

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

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

DM MPP 主备

MPP 主备就是在 MPP 集群的基础上，为每一个 MPP 节点配置一套实时主备系统，这些实时主备系统一起构成了 MPP 主备系统。 MPP 主备系统包含多个守护进程组，每个守护进程组都是一个相对独立的实时主备系统，具备实时主备的基本功能，可以进行主备切换、备库接管等操作。

MPP 主备的主要目的是为 DM MPP 集群提供数据可靠性保障，备库只做数据容灾、备份， MPP 备库并不是 MPP 集群的一部分，只是某个 MPP 节点（主库）的镜像。 MPP 备库不参与 MPP 操作，与其他 MPP 备库之间也没有任何关系， MPP 备库只能以单节点方式提供只读服务，但不提供全局的 MPP 只读服务。

MPP 主备系统中，一个守护进程 dmwatcher 可以监控、管理多个守护进程组的数据库实例。一般来说，一台物理机器上，可以部署 1 个 MPP 节点的主库和多个其他 MPP 节点的备库，充分利用硬件资源，节省投资。

Global 守护类型的 MPP 主备库需要在 dm.ini 中配置 MPP_INI 为 1，并且 MPP 主备库的本地数据文件目录下都需要有 dmmpp.ctl 文件，如果 Global 守护类型的备库没有上述配置，守护进程和监视器无法正常使用，守护进程会切换到 Shutdown 状态，监视器上无法正常执行命令，会打印配置不一致的提示信息。

下图以三个 MPP 节点，每个节点配备两个备库为例，说明 MPP 主备系统的结构。

• 功能扩展
  与实时主备系统相比，MPP 主备扩充了维护 MPP 控制文件功能，dmmpp.ctl 控制文件记录了 MPP 集群的节点信息，在主备库切换或者备库接管后，必须将新的主库信息更新到 dmmpp.ctl 文件中。

• 实时主备、 MPP 主备比较

类型	实时主备	MPP 主备
数据库类型	单节点	MPP 集群
备库数量	1~8	1~8
归档类型	实时归档	实时归档
归档时机	写入联机日志前，发送到备库	写入联机日志前，发送到备库
数据来源	RLOG_PKG	RLOG_PKG
更新 dmmpp.ctl	否	是 （只更新 MPP 主节点上的 dmmpp.ctl 文件）
是否支持 DMDSC 集群	支持	不支持

DM 读写分离集群

读写分离集群是基于即时归档或实时归档实现的高性能数据库集群，不但提供数据保护、容灾等数据守护基本功能，还具有读写操作自动分离、负载均衡等特性。读写分离集群最多可以配置 8 个即时备库或 8 个实时备库，提供数据同步、备库故障自动处理、故障恢复自动数据同步等功能，也支持自动故障切换和手动故障切换两种守护模式。

一般情况下，应用系统中查询等只读操作的比例远大于 Insert/Delete/Update 等 DML 操作，修改对象定义等 DDL 操作的比例则更低。但是，这些操作往往混杂在一起，在高并发、高压力情况下，会导致数据库性能下降，响应时间变长。借助读写分离集群，将只

读操作自动分发到备库执行，可以充分利用备库的硬件资源，降低主库的并发访问压力，进而提升数据库的吞吐量。

读写分离集群不依赖额外的中间件，而是通过数据库接口与数据库之间的密切配合，实现读、写操作自动分离特性。DM 的 JDBC、DPI、DCI、ODBC、Provider 等接口都可以用来部署读写分离集群。

根据是否满足读提交事务隔离级特性，读写分离集群可以配置为事务一致模式和高性能两种模式。简单的说，事务一致模式下，不论一个 Select 语句是在备库执行、还是在主库执行，其查询结果集都是一样的。高性能模式则不能保证查询是一致的，备库的数据与主库的数据同步存在一定的延迟，当 Select 语句发送到备库执行时，返回的有可能是主库上一个时间点的数据。

DMDSC 数据守护

DMDSC（数据共享集群）支持多个数据库实例同时访问、修改保存在共享存储中的数据，能够提供更高的数据库可用性和事务吞吐量。但由于数据是保存在共享存储上，当出现存储失效等故障时，数据库服务将会中断。

DM 数据守护包含多个数据库，主库和备库部署在不同的机器上，数据分别保存在各自的存储上，主库传递 Redo 日志到备库，备库重演 Redo 日志实现数据同步。因此，DM 数据守护在容灾（特别是异地容灾）方面具有明显的优势。为了进一步提高 DMDSC 集群的数据安全性，以及系统的可用性， DM 提供了 DMDSC 集群数据守护功能。

DMDSC 集群数据守护功能与单节点数据守护保持一致，支持故障自动切换，支持实时归档与读写分离集群。支持 DMDSC 集群的守护，DMDSC（主） 和 DMDSC（备）、DMDSC（主）和单节点（备）、单节点（主）和 DMDSC（备） 相互之间都可以作为主备库的数据守护。

以下示例为 DMDSC 和 DMDSC 互为主备的守护系统结构简图：

总体原则说明：

• DMDSC 集群各个节点分别部署守护进程 (dmwatcher)。
• DMDSC 集群数据库控制节点的守护进程，称为控制守护进程，普通节点的守护进程称为普通守护进程，如果控制节点发生变化，则控制守护进程也相应变化。
• 守护进程会连接 DMDSC 集群所有实例，但只有控制守护进程会发起 OPEN、故障处理、故障恢复等各种命令。普通守护进程不处理用户命令，但接收其他库的控制守护进程消息。
• 主备实时同步数据时，DMDSC 集群主库各个节点将各自产生的联机日志发送到备库控制节点（重演节点）进行重演，备库普通节点不接收日志。