在达梦数据守护集群中，自动故障切换的总耗时（即RTO）直接关系到业务恢复速度。各配置参数在故障检测、网络确认、备库接管和客户端重连等环节中的具体作用机制，在实际运维中往往容易被混淆。本文针对实时主备场景，通过网卡禁用实验，重点分析故障认定阶段各参数对主备故障切换时间的影响路径。

一次完整主备切换所需的时间构成

主备自动切换通常分为以下四个阶段：

其中阶段2弹性最大，也是本次实验的聚焦点。阶段3受物理条件约束较强，本文不做展开；阶段4在文末简单的单独讨论。

涉及主备切换时间的参数清单

根据达梦各配置文件的参数定义，与切换时间相关的参数汇总如下：

实验方法

· 环境：两台虚拟机（主/备），部署达梦数据守护集群，采用自动切换模式并配置确认监视器。

· 故障注入方式：禁用主库网卡（模拟物理拔线或网络静默中断），通过 date 命令记录故障发生时刻。

· 观测点：以监视器日志中的“检测到接收信息超时”和“检测到实例故障”两个关键事件时间为依据，计算各阶段耗时。

· 控制方法：每次仅调整目标参数，其余参数保持固定。

主要参数测试过程与分析

配置参数影响整个主备自动切换流程可以分为：故障发生->故障认定（影响参数主要是DW_ERROR_TIME和INST_ERROR_TIME如果是内部网络故障还有MAL_CHECK_INTERVAL和MAL_CONN_FAIL_INTERVAL）->备库接管（主要是硬件和日志量决定）->客户端服务器切换（SWITCH_TIMES和SWITCH_INTERVAL），先排除硬件的影响，研究故障认定这部分参数对时间的影响。

1. INST_RECOVER_TIME参数

根据DM8数据守护与读写分离集群文档，主库维护，滚动升级等场景，可以执行 Switchover 命令，实现主备库切换。主库故障、备库接管场景，故障自动切换模式下，确认监视器会自动选择符合条件的备库进行接管。故障手动切换模式下，可以在监视器上执行 Choose Takeover 命令，选出守护进程组中可以接管的备库。二者都会修改主库守护进程INST_RECOVER_TIME内存值为3秒（默认60秒），确保尽快启动故障恢复流程，同步主库数据完成后，重新将归档设置为Valid状态。不影响主备切换的速度，只影响切换后新主库多久开始同步数据。

2. 内部网络故障（dmmal.ini里对应的参数）

当内部网络是由于拔掉网线、或者禁用网卡等原因导致的故障，MAL 系统检测到链路断开的时间由 dmmal.ini 中配置的 MAL_CHECK_INTERVAL 以及 MAL_CONN_FAIL_INTERVAL 决定。会话的中断时间会比杀掉实例、掉电等花费的时间长。
根据文档配置，其效果为：

在linux虚拟机上验证参数的效果，MAL_CHECK_INTERVAL 以及 MAL_CONN_FAIL_INTERVAL均先设置成5。
在禁用网卡的同时打印故障发生时间：

然后守护进程自动切换备库：

可以看到在02秒发生的故障16秒检测到接收信息超时，16秒检测到实例故障，然后16秒成功接管，后续恢复网络。
接着把MAL_CHECK_INTERVAL 以及 MAL_CONN_FAIL_INTERVAL均设置成30。可以看到：11秒发生的故障25秒检测接收信息超时，57秒检测实例故障。


两次测试参数对比：

两次时间节点对比：

对比两组测试可知：从故障发生到“检测到消息超时”的时长（约14秒）并未随MAL参数变化而改变，说明该段时间由其他参数控制；而“检测到消息超时”到“确认实例故障”的间隔不同说明与MAL参数取值直接相关。即MAL参数影响的是消息超时后的故障确认阶段，取值越大，该阶段耗时越长，符合官方文档对参数的描述。

3. DW_ERROR_TIME与INST_ERROR_TIME

这两个参数共同决定了故障认定的总时长，但是参数并非"越小越好"，配置过短可能导致误切换，诱发脑裂等严重问题。过短的 DW_ERROR_TIME / INST_ERROR_TIME 可能会导致在轻微网络抖动时就触发了 TAKEOVER。
在接管执行期间，监视器收到了主库守护进程的备库故障确认消息，误认为主库守护进程没有在执行接管操作，允许主库守护进程切换为 FAILOVER 状态并打开主库，同时备库也成功切换为主库 → 组分裂（脑裂）。
为确定DW_ERROR_TIME与INST_ERROR_TIME影响的时间是不是检测消息超时这一部分的时间，继续接着上面的测试，这次mal的参数设置为10，将error的两个参数设置为20：


将 DW_ERROR_TIME 与 INST_ERROR_TIME 同时调至20秒后（MAL参数固定为10秒），“检测到消息超时”的时间由14秒延长至24秒，增量恰好等于ERROR参数的增幅；而从“消息超时”到“实例故障确认”则未产生额外延迟。
再试试把mal设置成30，error还是20：


这次可以看到从故障发生到检测消息超时花了24s，从消息超时到实例故障花了22s。可以得出结论，DW_ERROR_TIME与INST_ERROR_TIME就是影响检测消息超时这一部分的时间，mal那两个参数影响从消息超时到实例故障的时间。

4. SWITCH_TIMES与SWITCH_INTERVAL

这两个参数是达梦数据库客户端连接配置文件 dm_svc.conf 中的核心参数，它们不参与服务端的主备切换决策，而是决定了客户端应用程序在服务端切换完成后，多快能感知到新主库并重新建立连接，间接影响主备切换时间。

小结

通过上述分组对照实验，各参数在故障切换时间线中的定位已基本明确。总体来看，DW_ERROR_TIME 与 INST_ERROR_TIME 控制的是故障感知阶段的超时阈值，即从故障发生到集群检测到“消息超时”的时长；而 MAL_CHECK_INTERVAL 与 MAL_CONN_FAIL_INTERVAL 则在网络层故障（如拔线）场景下，进一步影响从“消息超时”到“确认实例故障”的确认阶段耗时。INST_RECOVER_TIME 不参与切换触发，仅作用于切换完成后的数据恢复流程；SWITCH_TIMES 与 SWITCH_INTERVAL 则完全作用于客户端驱动层，与服务端切换决策无关。

需要特别说明的是，在实际生产环境中，上述参数之间并非严格的串联累加关系。DW_ERROR_TIME 与 INST_ERROR_TIME 的超时判断依赖于守护进程与数据库实例的心跳状态，而MAL参数仅在网络链路层故障时才会介入计时——当故障类型为进程崩溃或掉电时，MAL参数的调节几乎不会产生额外影响；只有在拔网线、禁用网卡等“静默中断”场景下，MAL相关参数才会叠加到总时长中。此外，DW_ERROR_TIME 的取值也会影响监视器对守护进程状态的判断，进而间接影响MAL链路中断后的切换决策流程。各参数之间通过守护进程、MAL系统和监视器三者之间的消息交互形成耦合，实际的切换耗时是多种因素综合作用的结果，难以用一个简单的加法公式完全概括。

因此，在实际调优中，不宜孤立地调整单个参数，而应结合网络架构的冗余程度、故障类型的可能性分布以及业务对RTO的容忍度，进行综合评估。同时需注意，过度缩短 DW_ERROR_TIME 与 INST_ERROR_TIME 虽能加快故障感知速度，但在网络瞬时抖动或系统高负载时极易引发误切换，进而导致脑裂风险，恢复成本远高于短暂的服务中断。所有参数调整应在测试环境中充分验证后，再逐步推广至生产环境。
https://eco.dameng.com