达梦数据库带DATA WATCH的三节点DSC故障节点清理和动态重加入

环境说明：银河麒麟v10、DM8、带一个实时备库的三节点DSC集群

问题描述：在压测过程中，第三个节点数据库连接突然中断，其他两个节点可正常提供服务。重启节点三的数据库服务，未报错，但从监视器dmcssm观察到，CSS、ASM服务均正常，只是该节点DB中的inst_status变为了AFTER REDO的状态，无法OPEN，其他指标均为正常状态。

查找原因：

▲参考博文：https://eco.dameng.com/community/article/2f00e579b9d7f22240b4d4e12e3212ac

数据库的After Redo 状态为，系统启动过程中联机日志重做完成后，回滚活动事务前设置为 After Redo 状态，数据守护集群的主机服务状态变化是先以mount状态启动，然后切换成after redo，最后切换成open。其中 mount状态是完成数据库的redo操作，after redo状态是完成数据库的undo操作，redo和undo都完成后才会切换成open。

尝试解决：

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

1、猜测会否也像博文中提到的一样，在Undo过程中出现了异常。于是修改了节点3的dmini参数PSEG_RECV=0，后重新启动该节点的数据库服务，观察到服务启动依然正常未报错，但状态依旧为AFTER REDO未改变。

▲注：PSEG_RECV为系统故障重启时，对活动事务和已提交事务的处理方式。0：跳过回滚活动事务和 PURGE 已经提交事务的步骤。在回滚表空间出现异常、损坏、系统无法正常启动时，可将 PSEG_RECV设置为 0，让系统启动；但存在一定风险，未提交事务的修改将无法回滚，破坏事务的原子性；另外，已提交未 PURGE 的事务，将导致部分存储空间无法回收；1：回滚活动事务并PURGE 已经提交事务；2：延迟 PURGE 已提交事务，延迟回滚活动事务；3：回滚活动事务，延迟 PURGE 已提交事务。默认值为1。

2、是否为空间不足导致。df -h、free -m查看了节点3的服务器空间使用情况，发现空间充足；通过dmasmtool进入asm磁盘文件中，删掉了归档日志盘中较早的归档日志，释放了部分空间；再次尝试重启数据库服务，依然未解决。

3、最终选择尝试先将坏掉的第三个节点从DSC集群中完全踢出，再通过动态扩展节点的方式重新加回集群中。

实施过程：

1）导出当前DSC集群的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）依次停止DSC集群所有节点的CSS、ASM和数据库服务，并删掉三个节点上配置文件中所有有关第三个节点的信息

./DmCSSServicePROD stop

./DmASMServicePROD stop

./DmService stop

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

4）修改导出的/dm/conf/dmdcr_cfg_bak.ini，删掉其中第三个节点的信息，并将组个数改为2，节点号中删掉2