【洞见症结】带DataWatch的三节点 DSC 集群故障案例分析（一）

本文系达梦数据资深技术工程师编写，主要分享其在重大项目实施过程中，对典型故障「DMDSC节点故障无法加入集群」的分析解决思路。

「DMDSC 共享存储集群」，是达梦攻克缓存交换技术难题推出的、目前国内唯一可对等替代 RAC 架构的全自研数据库集群产品，也是达梦当前面向核心业务系统最受欢迎的解决方案之一，目前已广泛应用在电网调控、银行核心交易、财政预算管理等重大核心项目中。

各位DMer有任何疑问，欢迎在文章底部留言讨论。

DMDSC 集群作为一种共享存储集群，具备高可用、高性能、负载均衡等企业级特性；DM 数据守护（DataWatch）作为一种数据库级的热备方案，也是数据库异地容灾的首选解决方案。本文主要记录了在带 DataWatch 的三节点DSC集群运维过程中遇到的典型问题的处理过程。

环境介绍

CPU架构：X86_64

操作系统：银河麒麟v10

数据库版本：DM8

集群环境：三节点DMDSC集群为主库，带一个实时备库

DSC节点故障无法加入集群

1. 故障描述

在压测加载数据过程中，DMDSC集群原本与第 3 个数据库节点建立的连接突然中断，其余两个节点可正常提供服务。重启节点 3 的数据库服务，未报错，但从监视器 DMCSSM 观察到 CSS、ASM 服务均正常，只是该节点DB中的 inst_status 变为了 After Redo 的状态，无法 OPEN ，其他指标均为正常状态。

2. 问题分析

数据库 After Redo 状态 ：系统启动或者实例崩溃恢复过程中联机重做日志应用完成后，回滚活动事务前的一种中间状态。

DMDataWatch集群的主机服务状态变化是先以 Mount 状态启动，然后切换成 After Redo，最后切换成 OPEN。数据库 Mount 后进行Redo操作，显示 After Redo 状态后数据库会进行Undo操作，Redo和Undo都完成后才会切换 OPEN。

3.解决办法

在解决DMDSC节点的问题之前，为尽量排除备库对DMDSC的影响，先在DMMONITOR中将备库进行了分离，即DMDSC到备库的实时归档状态设置为了 INVALID 。

方法一：假设故障节点是在Undo过程中出现了异常， 修改故障节点参数 PSEG_RECV

选择修改节点3的 dmini 参数 PSEG_RECV=0，先将该节点的数据库服务正常启动，后再改回原来的值。

PSEG_RECV：系统故障重启时，对活动事务和已提交事务的处理方式，默认值为1；

0：跳过回滚活动事务和 PURGE 已经提交事务的步骤；

在回滚表空间出现异常、损坏、系统无法正常启动时，可将 PSEG_RECV 设置为 0，让系统启动，但存在一定风险：未提交事务的修改将无法回滚，破坏事务的原子性；另外，已提交未 PURGE 的事务，将导致部分存储空间无法回收。

1：回滚活动事务并PURGE 已经提交事务；

2：延迟 PURGE 已提交事务，延迟回滚活动事务；

3：回滚活动事务，延迟 PURGE 已提交事务。

修改后重启故障节点的数据库服务，观察到服务启动依然正常未报错，但状态依旧为 After Redo ，未改变。

方法二：释放空间，消除空间不足对DMDSC各节点、主备之间日志传输与应用的干扰

1）df -h查看磁盘空间、free -m查看系统内存，发现空间充足。

2）怀疑是否是归档空间不足导致了日志应用的中断，最终导致故障一直处于 After Redo 的状态无法 OPEN 。于是我们尝试通过DMASMTOOL进入ASM磁盘文件中，删掉归档日志盘中较早的归档日志，释放了部分空间。

再次尝试重启数据库服务，依然未解决。

方法三：将故障节点从DSC集群中剔除，后动态扩展再加入

1）导出当前DMDSC集群的DCR盘信息到/dm/conf/dmdcr_cfg_bak.ini：

./dmasmcmd 
ASM>export dcrdisk '/dev/dmasm_dcr' to '/dm/conf/dmdcr_cfg_bak.ini'

2）登录DMASMTOOL，删掉共享盘中节点3的所有文件（在线日志文件、本地归档文件）

./dmasmtool dcr_ini=/dm/conf/dmdcr.ini
cd DGLOG01/LOG
rm -f  “prod2_log*”
cd DGARCH01
rm -rf  “LOCAL_ARCH_PROD2”

3）依次停止DMDSC集群所有节点的CSS、ASM和数据库服务，并删掉配置文件中所有与第三个节点相关的信息。

./DmCSSServicePROD stop
./DmASMServicePROD stop
./DmServicePROD stop

需要修改的配置文件为：

/dm/conf/dmmal.ini  dmarch.ini  dmasvrmal.ini

4）修改导出的/dm/conf/dmdcr_cfg_bak.ini，删掉与第三个节点相关的配置信息，并将组个数改为2，删掉第三个节点对应的序号。

5）使用修改后的/dm/conf/dmdcr_cfg_bak.ini重新初始化DCR和VOTE磁盘。

./dmasmcmd
init dcrdisk '/dev/dmasm_dcr' from '/dm/conf/dmdcr_cfg_bak.ini' identified by 'aaabbb'
init votedisk '/dev/dmasm_vote' from '/dm/conf/dmdcr_cfg_bak.ini'

6）重新启动节点1、2的CSS、ASM服务和数据库服务

7）在启动数据库过程中，报错，查看节点1日志

发现由于删除了节点3的在线日志文件，报找不到该文件的错，意识到可能是数据库启动时，会去控制文件中读取数据库的结构信息，而当前数据库控制文件dm.ctl中没有将节点3的信息删除。

8）从共享盘中将dm.ctl文件导出，手动删除掉节点3的在线日志文件信息，再导入。过程如下：

./dmctlcvt TYPE=1 SRC=+DGDATA01/DATA/PROD/dm.ctl DEST=/dm/conf/dmctl.txt DCR_INI=/dm/conf/dmdcr.ini
./dmctlcvt TYPE=2 SRC=/dm/conf/dmctl.txt DEST=+DGDATA01/DATA/PROD/dm.ctl DCR_INI=/dm/conf/dmdcr.ini

删除部分为：

# table space name
ts_name=RLOG
 # table space ID
ts_id=2
# table space status
ts_state=0
# table space cache
ts_cache=
# DSC node number
ts_nth=2
# DSC optimized node number
ts_opt_node=0
# table space create time
ts_create_time=DATETIME '2022-2-14 13:32:56'
# table space modify time
ts_modify_time=DATETIME '2022-2-14 13:32:56'
# table space encrypt flag
ts_encrypt_flag=0
# table space copy num
ts_copy_num=0
# table space region size flag
ts_size_flag=0

# file path
fil_path=+DGLOG01/LOG/prod2_log01.log
# mirror path
mirror_path=
# file id
fil_id=0
# whether the file is auto extend
autoextend=1
# file create time
fil_create_time=DATETIME '2022-2-14 13:32:56'
# file modify time
fil_modify_time=DATETIME '2022-2-14 13:32:56'
# the max size of file
fil_max_size=0
# next size of file
fil_next_size=0

# file path
fil_path=+DGLOG01/LOG/prod2_log02.log
# mirror path
mirror_path=
# file id
fil_id=1
# whether the file is auto extend
autoextend=1
# file create time
fil_create_time=DATETIME '2022-2-14 13:32:56'
# file modify time
fil_modify_time=DATETIME '2022-2-14 13:32:56'
# the max size of file
fil_max_size=0
# next size of file
fil_next_size=0

重新启动节点1、2上的数据库服务，正常。

9）删掉/dm/conf/dmcssm.ini中节点3的信息后，登录监视器可以看到，已经变为了2个节点，且集群处于正常状态。

10）动态加入第三个节点

① 再次导出DCR磁盘信息（同上）

② 登录节点1的DISQL，添加节点3的在线日志文件

./disql sysdba/SYSDBA:11236
SQL> alter database add node logfile '+DGLOG01/LOG/prod2_log01.log' size 2048,'+DGLOG01/LOG/prod2_log02.log' size 2048;

③ 修改导出的dmdcr_cfg_bak.ini文件，将组成员个数改为3，节点号都加上2，各个组加上节点3的信息

④ 将三个节点的配置文件dmmal.ini、dmasvrmal.ini、dmarch.ini都加上节点3的信息

⑤ 将修改后的dmdcr_cfg_bak.ini扩展进磁盘中

./dmasmcmd
ASM>extend dcrdisk '/dev/dmasm_dcr' from '/dm/conf/dmdcr_cfg_bak.ini'

⑥ 保险起见，这里先将3个节点的CSS、ASM及数据库服务卸载后重新注册，再依次启动，CSS、ASM均启动正常，数据库启动卡住，一直处于 STARTUP 状态

尝试在前台启动，也直接卡住

查看节点3的数据库日志，观察到在与备库133通信，猜测可能是由于实时备库存在的影响。

⑦ 由于当前未找到带实时备库的DMDSC动态扩展节点的官方可靠说明，现尝试直接丢掉备库，恢复DSC集群为Normal模式，然后将DMDSC备份，还原至133上，最后恢复主备关系。

a. 现节点1和2均正常，登录节点1、2的Disql，修改数据库模式为Normal

./disql sysdba/SYSDBA:11236
alter database mount;
alter database normal;
alter database open;

b. 此时启动第三个DMDSC节点的数据库服务，发现可成功启动，inst_status也变为了 OPEN，3节点DMDSC集群至此全部恢复正常！

11）重建主备关系

a. 已开归档，进行在线备份

backup database full backupset ‘/dm/backup/20220222’

b. 停止备库的守护进程、数据库服务，登录DMRMAN使用备份集20220222进行还原

c. 停止DMDSC集群节点1、2的数据库服务和守护进程，修改相关配置文件，加上备库信息，以Mount方式启动DMDSC数据库和备库，重新配置各自的数据库模式和oguid，oguid和之前保持一致

d. 最后启动DSC和备库的守护进程，登录监视器，发现主备也恢复了正常

---

总 结

1、数据库服务启动时会读取控制文件dm.ctl，若人为手动删除了数据库相关文件，比如某个用户表空间文件、在线日志文件等，需同时删掉dm.ctl中的相关信息数据库才可正常启动。

2、带备库的DMDSC动态扩展节点，异常情况下，可先断开主库关系，并将数据库模式从 Primary 置为 Normal 。待集群节点全部正常启动后，重新进行备份并还原到备库节点，最后恢复主备关系。

本文摘取自「 第一届达梦技术征文大赛」获奖作品，受限于篇幅和阅读体验，本次仅展示其中「DSC节点故障无法加入集群」故障的排查解决过程，下周我们将分享：

希望这篇分享能帮助DMer切实解决问题，有关本文内容、DAMENG PAI 数据库一体机或者更多DM相关问题，欢迎在文章底部留言讨论😁😁😁