达梦数据库状态

DM 数据库包含以下几种状态：

1. 配置状态（MOUNT）：不允许访问数据库对象，只能进行控制文件维护、归档配置、数据库模式修改等操作。
2. 打开状态（OPEN）：不能进行控制文件维护、归档配置等操作， 可以访问数据库对象，对外提供正常的数据库服务。
3. 挂起状态（SUSPEND）：与 OPEN 状态的唯一区别就是，限制磁盘写入功能。当触发 REDO 日志、数据页刷盘，当前用户将被挂起。

对于新初始化的库，首次启动不允许使用 mount 方式，需要先正常启动并正常退出，然后才允许 mount 方式启动。
mount <---> open <---> suspend
OPEN 状态与 MOUNT 和 SUSPEND 能相互转换，但是 MOUNT 和 SUSPEND 之间不能相互转换。

达梦数据库模式

DM 数据库包含以下几种模式：

1. 普通模式（NORMAL）：用户可以正常访问数据库，操作没有限制；
2. 主库模式（PRIMARY）：用户可以正常访问数据库，所有对数据库对象的修改强制生成 REDO 日志，在归档有效时，发送 REDO 日志到备库；
3. 备库模式（STANDBY）：接收主库发送过来的 REDO 日志并重做。数据对用户只读。

三种模式只能在 MOUNT 状态下设置， 模式之间可以相互转换。
某此数据库配置（如配置数据守护、数据复制），服务器需要指定 MOUNT 状态启动。

当数据库为 NORMAL 模式时，如果不指定 MOUNT 状态启动，则自动启动到 OPEN 状态。
当数据库为非 NORMAL 模式（PRIMARY、 STANDBY）时，无论是否指定启动状态，服务器启动时自动启动到 MOUNT 状态。

达梦数据守护方案介绍

DM 数据守护（Data Watch）通过主备库的方式提供数据库的容灾方案。

数据守护方案有以下几种：

1. 实时主备：基于实时归档。
2. 读写分离集群：基于即时归档或实时归档。
3. DMDSC 数据守护：与单节点数据守护一样，支持实时归档与读写分离集群。
4. MPP主备：在 MPP 集群的基础上，为每一个 MPP 节点配置一套实时主备系统，即基于实时归档。

以前，实时主备通常使用实时归档，读写分离集群通常使用即时归档。
目前，实时主备使用实时归档，读写分离集群即可以使用实时归档，也可以使用即时归档，但现在也多用实时归档。
实时主备和读写分离集群的搭建方法是一样的，区别在于客户端是否使用读写分离的连接方式。

DM实现读写分离集群的基本思路是利用备库提供只读服务、无法修改数据的特性，优先将所有操作发送到备库执行，一旦备库执行报错，则发送到主库重新执行。通过备库“试错”这么一个步骤，自然地将只读操作分流到备库执行。并且，备库“试错”由接口层自动完成，对应用透明。

DM 多种客户端接口都支持读写分离集群连接设置，“7 数据守护集群 > 7.3.9 接口说明”介绍了客户端连接服务器时如何设置读写分离属性，详细可参考《DM8 程序员手册》。

这儿以JDBC为例：

<DRIVER>dm.jdbc.driver.DmDriver</DRIVER> 
<URL>jdbc:dm://192.168.0.206:5236?rwSeparate=1&rwPercent=10</URL>

• rwSeparate 是否使用读写分离系统，缺省为 0；取值（0 不使用，1 使用）。
• rwPercent 分发到主库的事务占主备库总事务的百分比，有效值 0~100，缺省值25。

执行举例说明：

//事务开始
SELECT * FROM T; //首先在备库上执行
INSERT INTO T VALUES(1); //写操作转移到主库上执行
SELECT * FROM T; //事务未提交，还在主库上执行
COMMIT; //事务提交
SELECT * FROM T; //事务已提交，重新转移到备库上执行

守护进程介绍

守护进程支持本地守护和全局守护两种守护类型。

• 本地守护
  提供最基本的守护进程功能，监控本地数据库服务。如果实例使用 Mount 方式启动，守护进程会通知实例自动 Open，如果连续一段时间没有收到来自其监控数据库的消息，即认定数据库出现故障，根据配置（INST_AUTO_RESTART）确定是否使用配置的启动命令重启数据库服务。异步备库也是采用这种方式配置。
• 全局守护
  实时主备、MPP 主备和读写分离集群系统中，需要将守护进程配置为全局守护类型；DMDSC 数据守护除了仅配置异步备库，也需要将守护进程配置为全局守护类型。守护进程根据数据库服务器配置的归档类型以及 MPP_INI 参数情况，自动识别具体的集群类型（实时主备、MPP 主备、读写分离集群或 DMDSC 数据守护），全局守护类型在本地守护类型的基础上，通过和远程守护进程的交互，增加了主备库切换、主备库故障检测、备库接管、数据库故障重加入等功能。

配置全局守护类型后，守护进程守护的数据库实例，必须配置实时或即时归档，否则 dmwatcher 会启动失败。

关于守护进程模式的考虑（脑裂）

脑裂是同一个守护进程组中同时出现两个或者多个活动主库，并且这些主库都接收用户请求，提供完整数据库服务。
一旦发生脑裂，将无法保证数据一致性，对数据安全造成严重后果。

造成脑裂的主要原因有两个：网络不稳定或错误的人工干预。
DM 数据守护系统为预防脑裂做了大量工作，例如：

• 故障自动切换模式的数据守护必须配置确认监视器。
• 确认监视器启动故障切换之前，会进行严格的条件检查，避免脑裂发生。
• 守护进程一旦检测到脑裂发生，会马上强制退出主库，等待用户干预，避免数据差异进一步扩大。

对于金融场景，我们宁愿短暂地停止服务，也不要数据不一致。

为了避免出现脑裂，我们建议：

1. 不使用自动模式，将 DW_MODE 设置为 MANUAL。
2. 采用虚拟化平台的高可用方案，当物理机故障时，主库虚拟机也能迅速在其它主机拉起来。
3. 设置 dm.ini 参数 ALTER_MODE_STATUS=0，限制用户进行直接通过 SQL 修改数据库模式、状态以及 OGUID。
4. 人工将备库切换为主库之前，一定要确认主库已经发生故障，避免主库活动情况下，备库强制接管，人为造成脑裂。
5. 如果要使用自动模式，要提供稳定、可靠的网络环境。将确认监视器部署在独立的第三方机器上。
   部署在三方机器可以避免由于网络问题触发自动故障切换，导致脑裂发生。例如，如果将监视器与主库部署在一起，主库服务器故障则监视器也将一起受到影响，如果将监视器与备库放到一起，如果主备机房间的通信发生问题，有可能导致监视器将备库切为主库，但原主库其实并没有死，仍在对外提供服务，此时，就有两套主库在对外提供服务。

监视器相关概念

监视器的作用：

• 监控数据守护系统
  接收守护进程发送的消息，显示主、备数据库状态变化，以及故障切换过程中，数据库模式、状态变化的完整过程。
• 管理数据守护系统
  用户可以在监视器上输入命令，启动、停止守护进程的监控功能，执行主备库切换、备库故障接管等操作。
• 确认状态信息
  用于故障自动切换的数据守护系统中，主、备库进行故障处理之前，需要通过监视器进行信息确认，确保对应的备库或者主库是真的产生异常了，避免主备库之间网络故障引发脑裂。
• 发起故障自动接管命令
  用于故障自动切换的数据守护系统中，主库发生故障时，挑选符合接管条件的备库，并通知备库执行接管操作

监视器的类型：

监视器分为两种类型：普通监视器和确认监视器。监视器类型由配置文件（dmmonitor.ini）的 MON_DW_CONFIRM 参数来确定，默认值是 0，表示普通监视器；参数值为 1 时表示确认监视器。普通监视器和确认监视器可以在系统中同时存在，也可以只配置其中一种。故障自动切换模式下，必须配置确认监视器。

一个数据守护系统中，最多允许同时启动 10 个普通监视器。多个普通监视器之间的关系为相互独立，互不干扰。所有普通监视器都可以接收守护进程消息，获取守护系统状态，也可以执行各种监控命令。所有监视器都可以发起 Switchover 等命令，但守护进程一次只能接收一个监视器的命令，在一个监视器命令执行完成之前，守护进程收到其他监视器发起的请求，会直接报错返回。

一个数据守护集群中，可以配置多个确认监视器，但同一时间，只能一个处于工作状态。确认监视器和普通监视器的区别在于，除了具备普通监视器所有功能之外，确认监视器还具有状态确认和自动接管两个功能。在数据守护系统的故障自动切换模式下，必须部署一个确认监视器，否则在出现数据库故障时，会导致数据库服务中断。DM 提供了两种确认监视器的配置形式，分别为单实例和多实例。当单实例确认监视器故障时，无法继续进行集群的故障自动接管和备库故障确认，影响正常使用，故 DM 提供了多实例确认监控器来进一步提高集群的高可用性。

守护进程 AUTO 模式下，必须配置确认监视器，且确认监视器最多只能一个处于工作状态，可以同时部署普通监视器。
守护进程 MANUAL 模式下，配置普通监视器即可。监视器可以安装在单独的机器上，也可以安装在数据库服务器上。

4.0 版本中，监视器的监控命令和管理命令只能在前台启动的监视器中执行，后台启动的监视器不能输入命令。