达梦数据库监视器
一般情况下监视器在数据守护主备集群中有较多的使用场景，数据守护系统的结构图如下
数据守护系统主要由主库，备库，Redo 日志传输，Redo 日志重演，守护进程和监视器组成
通过监视器可以监控数据守护系统的运行情况，获取主备库状态，守护进程状态以及主备库数据同步情况等信息，还可以通过在监视器上执行一系列命令对数据守护系统进行管理
监视器分为两种类型，分别为普通监视器和确认监视器；当设置为普通监视器时，集群中出现故障时需要手动对主备节点进行切换操作，而确认监视器可以在检测到系统故障时对实例进行自动切换；监视器类型由监视器配置文件 dmmonitor.ini 中的 MON_DW_CONFIRM 参数决定，该参数设置为 0 即表示该监视器为普通监视器，设置为 1 则表示该监视器为确认监视器
普通监视器
普通监视器 dmmonitor.ini 配置如下
MON_DW_CONFIRM = 0 #0：非确认（故障手切） 1：确认（故障自切）
MON_LOG_PATH = /opt/dmdbms/log2 #监视器日志文件存放路径
MON_LOG_INTERVAL = 60 #每隔 60s 定时记录系统信息到日志文件
MON_LOG_FILE_SIZE = 512 #单个日志大小，单位 MB
MON_LOG_SPACE_LIMIT = 2048 #日志上限，单位 MB
[GRP1]
MON_INST_OGUID = 45331 #组 GRP1 的唯一 OGUID 值
MON_DW_IP = 10.0.0.5:5436 #IP 对应 MAL_HOST，PORT 对应 MAL_DW_PORT
MON_DW_IP = 10.0.0.7:5436
一个数据守护系统中，最多允许同时启动 10 个普通监视器。多个普通监视器之间的关系为相互独立，互不干扰
所有普通监视器都可以接收守护进程消息，获取守护系统状态，也可以执行各种监控命令。所有监视器都可以发起 Switchover 等命令，但守护进程一次只能接收一个监视器的命令，在一个监视器命令执行完成之前，守护进程收到其他监视器发起的请求，会直接报错返回
确认监视器
确认监视器和普通监视器的区别在于，除了具备普通监视器所有功能之外，确认监视器还具有状态确认和自动接管两个功能。在数据守护系统的故障自动切换模式下，必须部署一个确认监视器，否则在出现数据库故障时，会导致数据库服务中断。DM 提供了两种确认监视器的配置形式，分别为单实例和多实例
一个数据守护集群中，最多只能配置一个确认监视器
当单实例确认监视器故障时，无法继续进行集群的故障自动接管和备库故障确认，影响正常使用，故 DM 提供了多实例确认监控器来进一步提高集群的高可用性
单实例
单实例确认监视器 dmmonitor.ini 配置如下
MON_DW_CONFIRM = 1 #0：非确认（故障手切） 1：确认（故障自切）
MON_LOG_PATH = /opt/dmdbms/log2 #监视器日志文件存放路径
MON_LOG_INTERVAL = 60 #每隔 60s 定时记录系统信息到日志文件
MON_LOG_FILE_SIZE = 512 #单个日志大小，单位 MB
MON_LOG_SPACE_LIMIT = 2048 #日志上限，单位 MB
[GRP1]
MON_INST_OGUID = 45331 #组 GRP1 的唯一 OGUID 值
MON_DW_IP = 10.0.0.5:5436 #IP 对应 MAL_HOST，PORT 对应 MAL_DW_PORT
MON_DW_IP = 10.0.0.7:5436
简单来说单实例确认监视器和普通监视器在配置文件上的差别就是 MON_DW_CONFIRM 参数的配置不同，在功能上的差别就是可以进行集群的故障自动接管和备库故障确认
多实例
为了防止单实例监视器故障时集群情况无法通过监视器得以确认，DM 提供了多实例确认监视器系统，多实例确认监控器提供的功能与单实例确认监控器相同，但是只能在 leader 监视器上进行监视器的相关操作，非 leader 监视器只能执行 show state 命令查看当前该监视器实例身份和当前 leader 监视器位于哪个实例
多实例确认监视器采用 RAFT 协议实现。在多实例确认监视器中，只有一个实例作为确认监视器提供服务，其它实例作为备库存在而不提供服务。当确认监视器出现故障时，系统会从它的备库中选举一位作为新的确认监视器继续提供服务
RAFT 协议
RAFT 协议是一种分布式数据一致性算法，通常应用在分布式系统中，用于保证多个服务器之间数据和状态的一致以及故障容错
一个 RAFT 集群包含多个节点，在任意时刻，每一个服务器节点都处于以下的几种状态之一：Leader、Follower 或 Candidate。通常情况下，系统中有且只有一个 Leader，其它节点都是 Follower。Follower 被动地响应来自 Leader 或 Candidate 的请求；Leader 由选举产生，并负责处理所有来自外部的请求；而 Candidate 则是在选举产生 Leader 的过程中由 Follower 临时切换而来的
RAFT 协议把从开始选举 Leader，到被选举出的 Leader 失效为止的一段时间称为任期（Term）。我们用连续且递增的整数来标记 Raft 集群中先后产生的每一个任期，这些整数被称为任期号。每一个节点存储一个当前任期号，这一编号随时间单调递增。当服务器之间通信的时候会交换当前任期号；如果一个服务器的当前任期号比其他节点小，那么他会更新自己的编号到较大的编号值。如果一个 Candidate 或者 Leader 发现自己的任期号过期了，那么他会立即恢复成 Follower 状态。如果一个节点接收到一个包含过期的任期号的请求，那么他会直接拒绝这个请求
角色状态说明
由于多实例确认监视器是基于 RAFT 协议实现的监视器集群，故在任意时刻，多实例确认监视器中的每一个实例节点也处于 Leader、Follower 或 Candidate 的状态之一
以下是各角色在多实例监视器中的作用和特点的说明：
Leader：主监视器。作为确认监视器向主备集群提供状态确认、自动接管等服务。正常情况下，一个多实例确认监视器集群中最多只存在一个 Leader。在多实例确认监视器的任意节点上执行 show state 命令，可以查看到当前作为 Leader 的节点
Follower：备监视器。作为 Leader 的备机而存在，不向主备集群提供服务，不允许执行除 show state 之外的监视器命令
Candidate：候选监视器。Leader 还未选出或者 Leader 异常时，Follower 会主动发起选举选出新 Leader，在发起选举时会切换为此角色。当任一 Candidate 收到监视器集群内大多数节点的选票后，则会切换为 Leader；当任一 Candidate 落选（即其他 Candidate 节点被选为新 Leader）则会切换为 Follower
Not leader：非主监视器。此状态不属于 RAFT 协议的内容，仅用于 show state 命令中打印显示使用。在无法识别对方是 Follower 还是 Candidate，但可以确定对方不是 Leader 的情况下会将其状态显示为 Not leader。由于在 RAFT 算法之中非 Leader 节点之间的通信较少，大部分情况下两个节点之间只能互相确定对方是否为 Leader；而当对方不是 Leader 时，不能确定对方是 Follower 还是 Candidate。因此，当使用监视器的 show state 命令查看所有节点的状态时，通常会将除 Leader 和自身之外的节点都显示为 Not leader 状态
选举规则
多实例确认监视器的选举过程完全遵守 RAFT 算法的要求。Leader 会周期性地向其它节点发送心跳信号来维持自己的地位。当某节点超过一定时间没有收到来自 Leader 的消息时，该节点就会发起选举
每次发起选举时，节点会切换为 Candidate，并将自己的任期号加 1，从而废黜旧 Leader，然后向其余节点发送投票请求。选举过程通过投票完成，每个任期中每个节点有且仅有一张选票，每个节点只会投给与自己相比符合选举要求的节点（有效日志比自己多）；发起选举的节点会直接将票投给自己，其余节点先收到的投票请求先处理，符合要求就会直接投出选票，不会考虑后续收到的投票请求。当发起选举的节点收到超过整个监视器集群节点数一半（包括自己）的选票，就会成为这个新任期的 Leader
需要注意的是，上述的任期号和日志信息由多实例确认监视器内部进行维护，对于用户是不可见的。因此，对于用户来说，主监视器的选举具有随机性。另外，由于上述规则的限制，需要确保多实例确认监视器中始终有超过半数的节点存活且有效，这样才能正常选举出主监视器作为确认监视器
文件配置
多实例确认监视器 dmmonitor.ini 配置如下
MON_DW_CONFIRM = 1 #确认监视器模式
MON_LOG_PATH = /home/dmdba/dm/dmdbms/log
MON_LOG_INTERVAL = 60
MON_LOG_FILE_SIZE = 32
MON_LOG_SPACE_LIMIT = 0
MON_INST_NUM = 3 ##实例总个数
MON_HB_INTERVAL = 60 ##通信心跳校验间隔
MON_BRO_INTERVAL = 100 ##raft协议中实例通信心跳间隔
MON_VOTE_INTERVAL = 100 ##raft协议中基础投票间隔
MON_ID = 1 ##当前监视器在监视器系统中的ID，监视器节点序号设置为1，主备依次往后
MON_MID = 45614 ##当前监视器系统的唯一标识
[GRP_RW]
MON_INST_OGUID = 453331
MON_DW_IP = 192.168.244.140:52141
MON_DW_IP = 192.168.244.141:52142
[MON1]
MON_HOST = 192.168.244.142 ##系统监听TCP连接的IP地址
MON_PORT = 8340 ##系统监听TCP连接的端口号
MON_INST_ID = 1 ##监视器实例在监视器系统中的ID
[MON2]
MON_HOST = 192.168.244.140 ##系统监听TCP连接的IP地址
MON_PORT = 8340 ##系统监听TCP连接的端口号
MON_INST_ID = 2 ##监视器实例在监视器系统中的ID
[MON3]
MON_HOST = 192.168.244.141 ##系统监听TCP连接的IP地址
MON_PORT = 8340 ##系统监听TCP连接的端口号
MON_INST_ID = 3 ##监视器实例在监视器系统中的ID
和单实例监视器配置文件不同，多实例监视器配置文件需要额外填写若干确认监视器参数和监视器组参数，额外的确认监视器参数包括 MON_INST_NUM 表示多实例监视器中实例的总个数，MON_HB_INTERVAL 表示各实例通信心跳校验间隔，MON_BRO_INTERVAL 表示各实例通信的心跳间隔，MOIN_ID 表示该监视器实例在该多实例监视器系统中的唯一标识，MON_MID 编号相同的表示属于同一个数据守护系统
各实例通信的心跳间隔以及基础投票间隔会在真正使用时进行调整，各实例通信心跳间隔需要比基础投票间隔小，若配置中各实例通信心跳间隔比基础投票间隔大，内部会将实例通信心跳间隔调整为与基础投票间隔相同，再进行其他的调整处理
多实例监视器中的每一个监视器实例都要配置一份 dmmonitor.ini 配置文件，而且在不同的配置文件当中除了 MON_ID 必须设置为不同以区分各实例外，其余所有参数都必须相同
多实例确认监视器配置测试
本地部署一主一备三监视器集群进行测试，单独的监视器节点需要安装 DM 数据库，各个监视器实例配置文件如下
主机节点
备机节点
监视器节点
主备集群启动后分别在监视器节点，主机节点和备机节点启动监视器实例，执行 show state 查看监视器节点角色如下
主机节点
备机节点
监视器节点
多次试验之后得出结论，在多实例监视器系统中，首个 leader 监视器为首个启动的监视器节点
尝试退出当前为 leader 监视器的监视器节点，观察情况如下
主机节点
备机节点
可以看到在监视器节点的监视器实例关闭后，剩下的主机节点和备机节点的监视器实例自动进行选举，并选举出主机节点作为当前的新 leader 监视器
关闭主机节点的监视器实例，备机节点观察情况如下
可以看到备机节点的监视器实例长时间处于选举状态，这是因为该监视器实例在选举过程中收到的票数一直少于该集群监视器数量的一半导致的，这就可以证明，在多实例监视器系统中，必须至少要有一半以上的监视器实例存活，系统才能选举出 leader 监视器，才能执行监视器的相关操作
达梦在线服务平台：https://eco.dameng.com
677
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
