DM数据库—数据守护

DM数据库—数据守护

​ 本次主要是DM数据库集群的相关概念、原理以及DM数据守护的一些说明。

概述

引言

• DM 数据守护（Data Watch）是一种集成化的高可用、高性能数据库解决方案，是数据库异地容灾的首选方案。通过部署 DM 数据守护，可以在硬件故障（如磁盘损坏）、自然灾害（地震、火灾）等极端情况下，避免数据损坏、丢失，保障数据安全，并且可以快速恢复数据库服务，满足用户不间断提供数据库服务的要求。
• DM 数据守护提供多种解决方案，可以配置成实时主备、MPP 主备、DMDSC 主备或读写分离集群，满足用户关于系统可用性、数据安全性、性能等方面的综合需求，有效降低总体投入，获得超值的投资回报
  • 实时主备：由一个主库以及一个或者多个配置了实时（Realtime）归档的备库组成，其主要目的是保障数据库可用性，提高数据安全性。
    • 主库提供完整的数据库功能，备库提供只读服务。
  • MPP主备：在 MPP 集群的基础上，为每一个 MPP 节点配置一套实时主备系统，这些实时主备系统一起构成了 MPP 主备系统。
    • MPP 主备系统中各个数据守护组保持相对独立，当某个 MPP 主节点出现故障时，在其对应的数据守护组内挑选一个备库切换为主库后，就可以确保整个 MPP 集群的正常使用
  • DMDSC主备：支持 DMDSC 集群和单节点之间互为主备库，将 DMDSC 集群部署为主库，将单节点部署为备库。
  • 读写分离集群：由一个主库以及一个或者多个配置了即时（Timely）归档或实时（Realtime）归档的备库组成，其主要目标是在保障数据库可用性基础上，实现读、写操作的自动分离，进一步提升数据库的业务支撑能力。

概述

• DM数据守护的实现原理：将主库（生产库）产生的 Redo 日志传输到备库，备库接收并重新应用 Redo 日志，从而实现备库与主库的数据同步。

  • 核心思想是监控数据库状态，获取主、备数据同步情况，为 Redo 日志传输与重演过程中出现的各种异常情况提供一系列的解决方案

    

• 守护进程：数据守护系统的核心工具，监控数据库实例的运行状态和主备库数据同步情况，在出现故障时启动各种处理预案。

  • 守护进程是各种消息的中转站，接收数据库实例、其他守护进程、以及监视器发送的各种消息；同时，守护进程也会将收到的数据库实例消息转发给其他守护进程和监视器
  • 后续会专门有一节进行讲解

• 监视器：用来监控守护系统内守护进程、数据库实例信息，执行用户输入命令、监控实例故障、实现自动切换等。

• 系统特性

  • 主要特征：
    • 完整功能的主库
      • 主库提供完整的数据库服务，与普通单节点数据库相比，主要的功能限制包括：不支持修改表空间文件名、不支持修改 arch_ini 参数
    • 活动的备库
      • 备库在 Open 状态下执行数据同步，是真正意义上的热备库；在实现异地容灾的同时，用户可以只读访问备库，执行报表生成、数据备份等功能，减轻主库的系统负载，提高资源利用率。
    • 多重数据保护
      • 每个备库都是一个完整的数据库备份，可以同时配置多个备库，为数据安全提供全方位的保护。
    • 高可用性
      • 主库出现故障时，可以快速将备库切换为主库，继续提供数据库服务，确保数据库服务不中断。
    • 多种守护模式
      • 提供自动切换和手动切换两种守护模式，满足用户不同需求。
    • 多种守护类型
      • 守护进程可以配置为全局守护（提供实时主备、MPP 主备、读写分离集群功能）或者本地守护，适应各种应用需求。
    • 故障自动重连
      • 配置、使用连接服务名访问数据库，在发生主备库切换后，接口会自动将连接迁移到新的主库上。
    • 故障库自动重加入
      • 主库故障，发生主备库切换。故障主库重启后，可以自动切换为 Standby 模式，作为备库重新加入数据守护系统。
    • 历史数据自动同步
      • 故障备库恢复后，可以自动同步历史数据，无需用户干预，并在同步完成以后，自动恢复为可切换备库。
    • 自动均衡负载
      • 配置读写分离集群，可以将只读操作分流到备库上执行，减轻主库访问压力，提高数据库系统的吞吐量。
      • 读写分离的过程由 JDBC 等接口配合服务器自动完成，无需用户干预，也不需要修改应用程序。
    • 滚动升级
      • 可以在不中断数据库服务的情况下，滚动地对数据守护系统中的主备库进行数据库软件版本升级。
    • 灵活的搭建方式
      • 可以在不中断数据库服务的情况下，将单节点数据库升级为主备系统。
    • 完备的监控工具
      • 通过命令行监控工具 dmmonitor、DEM 工具可以实时更新、监控主备库的状态和数据同步情况。
    • 完善的监控接口
      • 提供完善的数据守护监控接口，可以定制监控项，并方便地集成到应用系统中。
    • 丰富的守护命令
      • 提供主备库切换、强制接管等功能，通过简单的命令就可以实现主备库角色互换、故障接管等功能。
    • 支持DMDSC守护
      • 支持 DMDSC 和单节点、单节点和 DMDSC 之间互为主备的数据守护环境。

• 基本概念

  • DMDSC状态

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

  • 数据库模式

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

      • Normal模式：提供正常的数据库服务，操作没有限制。正常生成本地归档，但不发送实时归档（Realtime）、即时归档（Timely）和异步归档（Async）
      • Primary模式：提供正常的数据库服务，操作有极少限制。该模式下部分功能受限
      • Standby模式：可以执行数据库备份、查询等只读数据库操作

      ALTER DATABASE NORMAL; ##切换至Normal模式
      
      ALTER DATABASE PRIMARY;##切换至Primary模式
      
      ALTER DATABASE STANDBY;##切换至Standby模式
      

  • 数据库状态

    • DM 的数据库状态包括：

      • Startup状态：系统刚启动时设置为 Startup 状态
      • After Redo状态：系统启动过程中联机日志重做完成后，回滚活动事务前设置为 After Redo 状态
      • Open状态：数据库处于正常提供服务的状态，但不能进行归档配置等操作
      • Mount状态：数据库在 Mount 状态下，不能修改数据，不能访问表、视图等数据库对象，但可以执行修改归档配置、控制文件和修改数据库模式等操作，也可以执行一些不修改数据库内容的操作
      • Suspend状态：数据库在 Suspend 状态下，可以访问数据库对象，甚至可以修改数据，但限制 Redo 日志刷盘，一旦执行 COMMIT 等触发 Redo 日志刷盘的操作时，当前操作将被挂起
      • Shutdown状态：实例正常退出时设置为 Shutdown 状态

      

      • 我觉得很像操作系统中的进程状态，可能从这个方向要好理解些

  • MAL系统

    • MAL 系统是基于 TCP 协议实现的一种内部通信机制，具有可靠、灵活、高效的特性。
    • DM 通过 MAL 系统实现 Redo 日志传输，以及其他一些实例间的消息通讯。

  • OGUID

    • 数据守护唯一标识码，配置数据守护时，需要由用户指定 OGUID 值。

    • 同一守护进程组中的所有数据库、守护进程和监视器，都必须配置相同的 OGUID 值，取值范围为 0~2147483647。

    • 查询方式：

      SELECT OGUID FROM V$INSTANCE;
      

  • 守护进程组

    配置了相同 OGUID 的两个或多个守护进程，构成一个守护进程组

    • 组分裂
      • 同一守护进程组中，不同数据库实例的数据出现不一致，并且无法通过重演 Redo 日志重新同步数据的情况，称为组分裂。
      • 引起组分裂的主要原因：
        • 即时归档中，主库在将 Redo 日志写入本地联机 Redo 日志文件之后，发送 Redo 日志到备库之前出现故障，导致主备库数据不一致，为了继续提供服务，执行备库强制接管。
        • 故障备库重新完成数据同步之前，主库硬件故障，并且长时间无法恢复；在用户接受丢失部分数据情况下，为了尽快恢复数据库服务，执行备库强制接管，将备库切换为主库。
    • 脑裂
      • 脑裂是同一个守护进程组中同时出现两个或者多个活动主库，并且这些主库都接收用户请求，提供完整数据库服务。一旦发生脑裂，将无法保证数据一致性，对数据安全造成严重后果。
      • 造成脑裂的主要原因有两个：网络不稳定或错误的人工干预。
      • 为避免脑裂，DM数据库可以通过以下配置：
        • 设置 dm.ini 参数 ALTER_MODE_STATUS=0，限制用户进行直接通过 SQL 修改数据库模式、状态以及 OGUID
        • 提供稳定、可靠的网络环境
        • 配置自动切换数据守护时，将确认监视器部署在独立的第三方机器上，不要与某一个数据库实例部署在一起，避免由于网络问题触发自动故障切换，导致脑裂发生
        • 通过人工干预，将备库切换为主库之前，一定要确认主库已经发生故障，避免主库活动情况下，备库强制接管，人为造成脑裂

• 实时主备

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

  • 主要功能：

    1. 实时数据同步
       • 主备库通过实时归档完成数据同步，实时归档要求主库将 RLOG_PKG 发送到备库后，再将 RLOG_PKG 写入本地联机 Redo 日志文件
    2. 主备库切换
       • 主备库正常运行过程中，可以通过监视器的 Switchover 命令，一键完成主备库角色转换
       • 主备库切换功能可以确保在软、硬件升级，或系统维护时，提供不间断的数据库服务
    3. 自动故障处理
       • 备库故障，不影响主库正常提供数据库服务，守护进程自动通知主库修改实时归档为 Invalid 状态，将实时备库失效
    4. 自动数据同步
       • 备库故障恢复后，守护进程自动通知主库发送归档 Redo 日志，重新进行主备库数据同步
    5. 备库接管
       • 主库发生故障后，可以通过监视器的 Takeover 命令，将备库切换为主库，继续对外提供服务。如果配置为自动切换模式，确认监视器可以自动检测主库故障，并通知备库接管，这个过程不需要人工干预
    6. 备库强制接管
       • 如果执行 Takeover 命令不成功，但主库可能由于硬件损坏等原因无法马上恢复，为了及时恢复数据库服务，DM 提供了 Takeover Force 命令，强制将备库切换为主库
    7. 读写分离访问
       • 在备库查询的实时性要求不高的条件下，实时主备也可以配置接口的读写分离属性访问，实现读写分离功能特性

  • 归档流程

    

    • 主库生成联机 Redo 日志，当触发日志写文件操作后，日志线程先将 RLOG_PKG 发送到备库，备库接收后进行合法性校验（包括日志是否连续、备库状态是否 Open 等），不合法则返回错误信息，合法则作为 KEEP_RLOG_PKG 保留在内存中，原有 KEEP_RLOG_PKG 的 Redo 日志加入 Apply 任务队列进行 Redo 日志重演，并响应主库日志接收成功。当有多个备库时，主库需要收到所有备库的响应消息才继续后续操作。

• DMDSC数据守护

  ​ DMDSC（数据共享集群）支持多个数据库实例同时访问、修改保存在共享存储中的数据，能够提供更高的数据库可用性和事务吞吐量。

  ​ DM 数据守护包含多个数据库，主库和备库部署在不同的机器上，数据分别保存在各自的存储上，主库传递 Redo 日志到备库，备库重演 Redo 日志实现数据同步。因此，DM 数据守护在容灾（特别是异地容灾）方面具有明显的优势。

  • 总体结构

    

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

  • 系统连接

    • DMDSC 数据守护集群的守护进程和守护进程之间、监视器和守护进程之间、守护进程和 dmcss 之间都需要建立 TCP 连接，用于信息传递和命令执行。使用 TCP 连接的工具见下表：

      工具	TCP 连接说明
      监视器（dmmonitor）	连接所有的守护进程
      守护进程（dmwatcher）	1. 连接 DMDSC 集群内所有实例 2. 连接其他库的所有守护进程，但不连接 DMDSC 集群内其他实例的守护进程 3. 连接 DMDSC 集群内所有实例的 dmcss

    • 详细使用说明：

      • 控制守护进程连接所有 DMDSC 实例，发起 OPEN、故障处理、故障恢复等各种命令。普通守护进程不处理用户命令，但接收其他库的守护进程消息。
      • 控制守护进程定时发送消息给实例，普通守护进程不会发消息给实例。
      • 控制守护进程定时发送消息给其他库的守护进程以及监视器，普通守护进程只发送给监视器，不会发送给其他库的守护进程。
      • DMDSC 集群内部不同实例的守护进程之间不通信。
      • 普通守护进程连接 DMDSC 中所有实例，但只记录每个实例的信息，不做任何操作。同一个 DMDSC 集群内的所有守护进程之间不进行连接。
      • DMDSC 中每个实例存在多个守护进程的连接，向每个 dmwatcher 发送广播消息，但只可能接收控制守护进程的命令。
      • 不同库之间的守护进程都建立连接。
      • 守护进程和 dmcss 建立连接，部分监视器执行命令通过守护进程转发，由 dmcss 执行。

  • 归档配置

    1. DMDSC集群必须配置远程归档，用于DMDSC节点故障后的数据同步
    2. 如果归档目标是 DMDSC 集群，则归档的目标节点需要同时配置 DMDSC 集群所有实例，一个 DMDSC 集群作为一个整体进行配置，realtime/timely/async 归档配置要求 ARCH_DEST 配置目标 DMDSC 集群所有节点信息，以‘/’分割

  • 日志发送

    • 异步归档日志发送
      • 主库是单节点时，单节点实例直接收集本地的归档日志发送到备库
      • 主库是 DMDSC 集群时，控制节点扫描本地归档和远程归档目录，收集所有节点的归档日志文件，并发送到备库，普通节点不发送归档日志
    • 实时/即时归档日志发送
      • 单节点和 DMDSC 集群采用相同的处理逻辑，各节点将本实例产生的 Redo 日志直接发送到备库重演实例

  • 日志重演

    • 备库日志重演规则
      • DMDSC 实现机制保证多个实例不能同时修改一个数据页，不同节点对同一个数据页修改产生的 LSN 一定是唯一、递增的。
      • 单个节点 Redo 日志的 LSN 可能不连续，但所有节点 Redo 日志归并在一起后，LSN 一定是连续的。

  • 守护控制文件

    • 控制守护进程检测到本地 DMDSC 集群分裂时，会自动在 dm.ini 的 SYSTEM_PATH 路径下创建 dmwatcher.ctl 文件，记录 Split 分裂状态和分裂描述信息。
    • 如果数据库控制节点发生切换，控制守护进程也随之切换，新的控制守护进程从 SYSTEM_PATH 目录加载 dmwatcher.ctl 文件。

  • DMDSC集群的管理规则

    1. 控制守护进程的认定

       • 控制节点本地的守护进程就是控制守护进程。

       • 一旦控制节点故障，并且选出新的控制节点后，原控制守护进程降级为普通守护进程。

       • 普通守护进程一直保持在 Startup 状态下，控制守护进程可以进行各种状态切换。

       • 监视器部分命令比如 Show 命令、Startup database 命令等执行时，可能 DMDSC 所有节点都不是活动状态，此时需要选出一个 dmwatcher 作为控制守护进程

    2. 守护进程名与实例名的对应关系

       • 守护进程守护的本地实例名，称为守护进程名
       • 单节点的守护进程名，就是单节点的实例名
       • 对于 DMDSC 库的守护进程，由于收到的远程守护进程实例消息都是控制守护进程发送过来的，控制守护进程守护的是 DMDSC 控制节点，因此远程守护进程名也就是远程 DMDSC 库的控制节点实例名

    3. DMDSC库模式和状态的确认

       • 规则：
         1. 主实例还未选出，或者不存在正常的实例，则无法判断模式状态。
         2. 只根据 OK 数组中的节点来判断模式状态，在获取节点状态时要求 DMDSC 集群处于 Open 状态。
         3. 如果存在模式不同的实例，则无法判断。
         4. 如果存在非 Suspend/Mount/open 状态的节点实例，则直接返回此节点状态作为 DMDSC 集群状态。
         5. 如果实例状态不一致，则按照优先级方式确定 DMDSC 集群当前的状态，Suspend 状态优先级最高，Mount 次之，Open 最低。

    4. DMDSC故障检测时间与守护进程故障确认时间

       • 活动节点一旦检测到 MAL 链路出现异常，立即启动故障处理，进入 HPC_CRASH_RECV 状态
       • 守护进程根据 INST_ERROR_TIME 配置的时间超时检测实例是否故障，守护进程的故障处理优先级低于 DMDSC 的故障处理

    5. DMDSC库 OK/ERROR的认定

       • 原则：
         1. 如果找不到控制节点，则认为 ERROR；
         2. 如果在 DMDSC 的 OK_EP 数组中，存在非 OK 状态的实例，则认为 ERROR；
         3. 其余情况认为 DMDSC 库是 OK 的。

    6. 接收DMDSC库消息超时

       • 守护进程根据 inst_error_time 值判断接收本地库消息是否出现超时：若控制节点还未选出，认为 DMDSC 集群还未启动正常，则认定为消息超时；只要 DMDSC 库内有一个实例的消息未超时，就认为消息未超时

    7. 接收远程守护进程消息超时

       • 出现此种的两种情况：

         1. 如果守护进程的链路已经断开，认为超时；
         2. 如果接收远程守护进程消息超过配置的 DW_ERROR_TIME 时间，则认为超时。

         如果判断为消息超时，则设置远程守护为 ERROR 状态

    8. DMDSC主库发送归档异常

       • 守护进程可以通过配置参数 RLOG_SEND_THRESHOLD 监控主库到备库的归档发送情况。
       • DMDSC 集群中，主库任意一个节点归档发送异常，就认为出现异常，需要切换到 Standby_check 状态下对归档发送异常的备库进行处理。
       • 异常判断前提：
         1. RLOG_SEND_THRESHOLD 参数配置值大于 0。
         2. 存在有归档处于有效状态的备库，对 DMDSC 集群，只需要主库任意一个节点实例到备库的归档有效即可。

    9. DMDSC备库重演异常

       • 守护进程可以通过配置参数 RLOG_APPLY_THRESHOLD 监控备库的日志重演情况

• 异步备库

  • 异步备库一般用于历史数据统计、周期报表等对数据实时性要求不高的业务场合。异步归档时机可以选择在源库空闲的时候，可避免源库的业务高峰期同步数据对性能的影响。
  • 每个 Primary 或者 Standby 模式的库都可以配置最多 8 个异步备库。配置了异步备库的 Primary 或者 Standby 模式的库，统称为源库。

• 同步备库

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

守护进程

​ 守护进程（dmwatcher）是 DM 数据守护系统不可或缺的核心部件，是数据库实例和监视器之间信息流转的桥梁

主要功能

• 监控数据实例

  • 守护进程负责监控数据库运行状态，必要时重启数据库服务。
  • 守护进程和实例链路建立成功后，数据库实例定时发送信息到守护进程。
  • 守护进程更新本地记录的实例信息后，同时记录该时间戳。当检测到实例进程 ID 已经不存在或者超过一段时间没有收到实例消息（INST_ERROR_TIME），则会认定实例故障。

• 发送状态信息

  • 守护进程将监控的数据库实例信息和守护进程自身的信息（包括守护类型、守护模式、守护状态、守护日志、监视器执行序列号、执行返回码等）捆绑在一起，定时发送给其他守护进程和所有监视器。

• 监控其他守护进程

  • 接收并解析其他守护进程发送的消息，如果超过一段时间（DW_ERROR_TIME)没有收到远程守护进程消息，会将远程守护进程状态认定为 ERROR 状态。

• 接收监视器信息

  • 主备切换、备库接管等操作都是通过监视器命令进行，监视器将操作命令分解成多个步骤顺序执行。守护进程接收这些消息并通知实例进行相应操作，例如执行 SQL 语句修改实例模式、状态、INI 参数、设置归档状态等一系列动作，这些步骤依次执行完成后，即可完成主备库的切换或备库的接管等操作。

• 主备库启动运行

  • 数据守护系统刚启动时，所有实例处于 Mount 状态，守护进程处于 Startup 状态，启动时需要将实例转换到 Open 状态，守护进程也切换到 Open 状态，对外提供服务。

• 备库故障处理

  • 备库故障后，如果主备库之间的归档状态仍然有效，主库的守护进程会先切换为 Confirm 状态，等待确认监视器的确认消息，如果确认为符合故障处理条件，主库守护进程再切换至 Failover 状态，将故障备库的归档失效。

• 备库异常处理

  • 备库异常，指备库的数据库实例正常，但响应速度出现异常（比如网络异常、自身软硬件出现问题等）
  • 主库守护进程在 Open 状态下对日志发送速度进行检测，一旦检测到异常，主库守护进程会切换到 Standby check 状态，并通知主库将异常备库的归档失效，暂停到此备库的数据同步，避免拖慢主库性能。

• 主库故障处理

  • 主库故障后，确认监视器会捕获到故障信息，自动选出可接管的备库，并通知备库进行接管。备库接管由确认监视器自动触发，无需用户干预。

• 故障恢复处理

  • 故障恢复状态（Recovery）由守护进程自行判断是否切换，和监视器无关。

守护类型

• 本地守护

  • 提供最基本的守护进程功能，监控本地数据库服务。
  • 如果实例使用 Mount 方式启动，守护进程会通知实例自动 Open。
  • 如果连续一段时间没有收到来自其监控数据库的消息，即认定数据库出现故障，根据配置（INST_AUTO_RESTART）确定是否使用配置的启动命令重启数据库服务。

• 全局守护

  • 守护进程根据数据库服务器配置的归档类型以及 MPP_INI 参数情况，自动识别具体的集群类型。全局守护类型在本地守护类型的基础上，通过和远程守护进程的交互，增加了主备库切换、主备库故障检测、备库接管、数据库故障重加入等功能。

守护模式

• 故障自动切换

  • 主库发生故障时，确认监视器自动选择一个备库，切换为主库对外提供服务。

• 故障手动切换

  • 主库发生故障时，由用户根据实际情况，通过监视器命令将备库切换为主库。在用户干预之前，备库可以继续提供只读服务和临时表的操作。

两者机制上存在一定差距，主要差异如下：

比较内容	故障自动切换	故障手动切换
硬件要求	>=3 台机器	>=2 台机器
主库故障需要人工干预	否	是
备库 KEEP_RLOG_PKG	有（实时主备和 MPP 主备专用）	有（实时主备和 MPP 主备专用）
需要确认监视器	是	否
支持实时主备	是	是
支持 MPP 主备	是	是
支持读写分离集群	是	是
主库故障处理	备库自动接管	备库手动接管
备库故障处理	主库可能先进入 Confirm 状态，向确认监视器求证备库故障后， 再进行 Failover 处理。也可能直接 Failover 处理，具体参考 6.9 小节	主库直接 Failover 处理
主备库切换	支持	支持

守护状态

• Startup 守护进程启动状态，需要根据远程守护进程发送的状态信息，结合本地数据库的初始模式、状态和数据同步情况，确定本地数据库的启动模式和状态后，进入 Open 状态。

• Open 守护进程正常工作，监控数据库，并定时发送数据库的状态信息，接收其他守护进程发送的信息，接收监视器发送的用户请求。

• Shutdown 守护进程停止监控数据库状态，不再提供主备库切换、主备库故障处理和备库故障恢复等功能。

• Switchover 主备库正常情况下，手动主备切换过程中设置为 Switchover 状态。

• Failover 远程备库故障后，本地主库执行故障处理时，守护进程设置为 Failover 状态。

• Recovery 故障恢复同步历史数据过程中设置为 Recovery 状态。

• Confirm 通过监视器确认远程主（备）库是否活动的过程中，守护进程设置为 Confirm 状态。

• Takeover 主库确认故障后，备库手工接管或监视器通知自动接管过程中，守护进程设置为 Takeover 状态。

• Open force 借助监视器命令强制 Open 主库或备库实例时，守护进程设置为 Open force 状态。

• Error 超过一段时间（DW_ERROR_TIME）没有接收到远程守护进程消息，本地守护进程或监视器认定远程守护进程故障，修改远程守护进程为 Error 状态。

• Login check 监视器执行登录命令时，守护进程所处的状态。

• Mppctl update 修改主库 MPP 控制文件（dmmpp.ctl）时，守护进程所处的状态，只在 MPP 主备系统出现。

• Change arch 监视器执行 set arch invalid 命令时守护进程所处的状态。

• Standby check 主库守护进程监控到备库异常后，切换到此状态下通知主库修改此备库归档无效。

• Clear send info 清理主库上的归档发送信息时，守护进程所处的状态。

• Clear rapply stat 清理备库上的重演信息时，守护进程所处的状态。

• Unify ep 统一 DMDSC 集群各节点实例状态，或者各实例状态已经一致时，守护进程在 Startup 或 Open 状态下通知实例执行相关操作，都进入 Unify_ep 状态执行。

• Css process 监视器发起的对 DMDSC 集群的部分命令，比如启动、关闭、强杀 DMDSC 库，或者打开、关闭节点实例的自动拉起功能等命令，需要借助 dmcss 执行时，守护进程会切换到此状态下。

  

  • 守护进程主要工作在 Startup 和 Open 状态，几乎任何状态都可以转到这两种状态，并且这两种状态之间也可以相互转换

控制文件

• 控制文件仅用于记录本地数据库的分裂状态和分裂描述信息。守护进程在检测到本地库分裂时，自动创建 dmwatcher.ctl 文件，保存在本地库的 SYSTEM_PATH 路径下，并且文件中记录的状态一定是 Split 分裂状态。

守护进程命令

• 具体的命令参考如下：

  命令	含义
  help	显示帮助信息
  exit	退出守护进程
  status	显示守护进程运行状态信息
  show	显示所有守护进程组中的本地库信息
  show group group_name	显示指定守护进程组中的本地库信息
  show version	显示守护进程自身版本信息
  show monitor config	帮助监视器配置 ini 文件的信息
  show link	显示守护进程上的 tcp 连接信息

监视器

​ 监视器（dmmonitor）是基于监视器接口实现的一个命令行工具，是 DM 数据守护系统的重要组成部分。通过监视器，可以监控数据守护系统的运行情况，获取主备库状态、守护进程状态以及主备库数据同步情况等信息。

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

监视器类型

• 普通监视器

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

• 确认监视器

  • 确认监视器和普通监视器的区别在于，除了具备普通监视器所有功能之外，确认监视器还具有状态确认和自动接管两个功能。

  • 在数据守护系统的故障自动切换模式下，必须部署一个确认监视器，否则在出现数据库故障时，会导致数据库服务中断。

  • 单实例

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

  • 多实例

    • 多实例确认监控器提供的功能与单实例确认监控器相同。
    • 多实例确认监视器采用 RAFT 协议实现。在多实例确认监视器中，只有一个实例作为确认监视器提供服务，其它实例作为备库存在而不提供服务。当确认监视器出现故障时，系统会从它的备库中选举一位作为新的确认监视器继续提供服务。
      • RAFT协议：一种分布式数据一致性算法，通常应用在分布式系统中，用于保证多个服务器之间数据和状态的一致以及故障容错。（RAFT协议就像美国总统一样，有一个“总统”、一个“候选人”，其余的全是“公民”）

配置和启动监视器

• 普通监视器

  • 首先，通过 dmmonitor.ini 文件配置普通监视器

    • 配置 dmmonitor.ini，位于/dm/data 文件夹下

      MON_DW_CONFIRM 			= 0  	#普通监视器
      MON_LOG_PATH 			= /dm/data/log		#监视器日志文件存放路径
      MON_LOG_INTERVAL		= 60	#每隔60s定时记录系统信息到日志文件
      MON_LOG_FILE_SIZE 		= 32	#每个日志文件最大32M
      MON_LOG_SPACE_LIMIT 	= 0		#不限定日志文件总占用空间
      [GRP1]
      	MON_INST_OGUID 			= 453332 #组GRP1的唯一OGUID值
      #以下配置为监视器到组GRP1的守护进程的连接信息，以“IP:PORT”的形式配置
      #IP对应dmmal.ini中的MAL_HOST，PORT对应dmmal.ini中的MAL_DW_PORT
      	MON_DW_IP 				= 192.168.0.141:52141
      	MON_DW_IP 				= 192.168.0.142:52142
      	MON_DW_IP 				= 192.168.0.143:52143
      

      • MON_DW_IP 中的 IP 和 PORT 和 dmmal.ini 中的 MAL_HOST 和 MAL_DW_PORT 配置项保持一致。

  • 其次，启动监视器

    ./dmmonitor /dm/data/dmmonitor.ini
    

    • 至此，监视器就可以正常使用

• 确认监视器

  • 单实例
    • 需设置 dmmonitor.ini 中 MON_DW_CONFIRM=1，表示配置为确认监视器。其它内容和普通监视器的 dmmonitor.ini 用法一样。
  • 多实例
    • 多实例确认监视器系统中，每个实例配置一个 dmmonitor.ini。多个 dmmonitor.ini 中，除 MON_ID 参数不同以外，其他参数应完全一致。
    • 与配置单实例确认监视器相比，配置多实例监视器时组的配置信息不做更改，监视器实例的配置信息需要新增确认监视器特有的配置参数。

状态确认

• 故障自动切换模式数据守护系统中，主库守护进程监测到备库故障时，需要向确认监视器求证，确认备库是真的故障了，再启动故障处理流程将归档失效，避免引发脑裂。

• 状态确认只对故障自动切换数据守护系统有效，主库守护进程在满足一定条件时，会切换到 Confirm 状态，向确认监视器进行求证。

• 主库守护进程切换到 Confirm 之后，根据不同的场景决定是否切换为 Failover 状态并启动故障处理流程。

  

自动接管

• 故障自动切换模式下，确认监视器检测到主库故障后，根据收到的主备库 LSN、归档状态、MAL 链路状态等信息，确定一个接管备库，并将其切换为主库。

• 确认监视器启动自动接管流程的主要场景有三种，任何一种都会导致备库自动接管：

  1. 主库数据库实例异常终止，主库守护进程正常。
  2. 主库硬件故障、或者数据库实例和守护进程同时故障。
  3. 主库网络故障，主备库之间、主库与监视器之间连接异常。

  

• 如果要实现备库自动接管，主库、归档状态、备库都得符合条件：

  • 主库
    • 主库是 Primary 模式、Open 状态时，产生故障。（如上图左、中）
    • 主库守护进程故障，故障前是 Open/Recovery 状态。（如上图中）
    • 故障主库与接管备库和确认监视器之间的 MAL 链路断开。（如上图右）
  • 归档状态
    • 故障主库到接管备库的归档状态为 Valid。
  • 备库
    • 接管备库是 Standby 模式、Open 状态。

监视器命令

• 监视器命令和说明如下：

  • 系统全局命令

    命令	含义
    help	显示帮助信息
    exit	退出监视器
    show version	显示监视器自身版本信息
    show global info	显示所有组的全局信息
    show database [group_name.]db_name	显示指定库的详细信息
    show [group_name]	显示指定组的实例信息，如果未指定组名，则显示所有组信息
    show i[nterval] n	每隔n秒自动显示所有组的实例信息
    q	取消自动显示
    list [[group_name.]db_name]	列出指定组的库对应的守护进程配置信息，如果都未指定，则列出所有守护进程配置信息
    show open info [group_name.]db_name	显示指定库的Open历史信息
    show arch send info [group_name.]db_name	查看源库到指定组的指定库的归档同步信息(包含恢复间隔信息)
    show apply stat [group_name.]db_name	查看指定组的指定库的日志重演信息
    show monitor [group_name[.]] [db_name]	列出连接到指定守护进程的所有监视器信息
    tip	查看系统当前运行状态
    login[/@service_name]	登录监视器。若指定了/@service_name，则会使用wallet方式登录监视器；若没有指定，则为默认的交互式登录
    logout	退出登录
    get takeover time [group_name]	获取备库开始自动接管需要延迟等待的时间
    show state	显示当前监视器所在监视器配置组的所有监视器的状态信息

监视器LOG日志

• 监视器 LOG 日志记录监视器自己的信息和守护进程的本地信息。
• 监视器 LOG 日志的命名格式为“dmmonitor_年月日时分秒.log”，例如“dmmonitor_20160418230523.log”。

总结

• 通过对数据守护以及集群的概念和原理学习，我理解了数据守护的目的和运作情况。同时对守护进程和监视器的学习，让我从更细节的方面理解数据守护的运作形式。

参考

e] | 登录监视器。若指定了/@service_name，则会使用wallet方式登录监视器；若没有指定，则为默认的交互式登录 |
| logout | 退出登录 |
| get takeover time [group_name] | 获取备库开始自动接管需要延迟等待的时间 |
| show state | 显示当前监视器所在监视器配置组的所有监视器的状态信息 |

监视器LOG日志

• 监视器 LOG 日志记录监视器自己的信息和守护进程的本地信息。
• 监视器 LOG 日志的命名格式为“dmmonitor_年月日时分秒.log”，例如“dmmonitor_20160418230523.log”。

总结

• 通过对数据守护以及集群的概念和原理学习，我理解了数据守护的目的和运作情况。同时对守护进程和监视器的学习，让我从更细节的方面理解数据守护的运作形式。

参考

• 达梦官网：概述 | 达梦技术文档 (dameng.com)