一、问题描述

    4 月 30 日 08:19 设备开机启动后，主备集群备机节点启动异常，相关服务无法正常初始化，始终启动失败，未能成功接入集群。异常状态持续至 08:56随后对故障备机进行重启处置，设备重启完成后，备机各项服务正常拉起，顺利并入集群，主备架构恢复完整，系统冗余备份与容灾能力恢复正常。

二、主库日志分析

1、dmap 服务日志分析

    从dmap日志核查可见，dmap 服务呈现每日固定时段规律性关闭、重启特征，初步判断疑似服务器存在每日自动关机后定时上电开机的调度。日志关键时间节点：4 月 28 日 19:00:45 服务关闭；4 月 29 日 06:49:09 服务重新启动；4 月 29 日 22:38:03 再次关闭；4 月 30 日 08:19:21 重启上线。

2、message日志

    核查操作系统日志可进一步佐证，数据库存在每日规律性开关机行为，整体呈现夜间自动关机、次日早间自动开机的固定周期规律。结合日志时间节点可见，服务器及数据库每日均按固定时段执行关停与启动操作，属于常态化定时启停模式。正是受这种每日定时开关机机制影响，4 月 30 日早间开机后，主备集群备机未能正常初始化启动，引发启动异常故障，需进一步核查。

3、Dmserver 日志

    4 月 30 日 08:19:21，DM2 实例启动，于 08:19:27 成功启动，角色为 primary，实例状态为 mount。但实例未能自动切换至 open 状态，集群服务无法正常提供读写能力。直至 08:58:53，数据库才由 dw 进程强制切换至 open 状态，完成最终启动。

4、DW日志

    4 月 30 日 08:19:21，DM2 守护进程正常启动，但无法接收到 DM1 实例守护进程通信消息，节点间心跳与状态同步异常。在此期间 DM2 实例虽已拉起并处于 Mount 状态，却无法正常进入 Open 就绪状态。
    直至 08:58:53，系统将 DM1 归档状态置为无效后，强制把 DM2 数据库切换至 Open 状态；随后成功接收到 DM1 实例守护进程上报消息，完成对DM1 实例及守护进程运行状态的校验确认。
    08:58:57，集群正式启动实例恢复流程，开始向节点推送归档日志，逐步完成数据同步与集群状态修复。

备库日志分析

1、 dmap 服务信息

    查阅备库 dmap 服务日志可明确，备机同样存在每日定时开关机的固定规律。关键时间节点如下：4 月 28 日 19:00:45 服务关闭；4 月 29 日 06:49:15 服务启动；4 月 29 日 22:38:03 再次关闭；4 月 30 日 08:19:18 正常启动。

2、备库 message 信息

    核查操作系统日志，其记录的启停时间与备库 dmap 服务日志高度吻合，进一步印证备机存在每日定时开关机的规律。系统日志关键时间节点：4 月 28 日 19:00:44 关机；4 月 29 日 06:48:45 开机启动；4 月 29 日 22:38:02 关机；4 月 30 日 08:18:57 正常开机；故障处置阶段：4 月 30 日 08:56:48 手动关机，08:58:26 重新开机。
    系统日志与应用日志时间基本一致，充分证实备机存在固定周期自动启停机制，也是本次主备集群备机启动失败的重要诱因。

3、dmserver 日志

    从日志记录可以看出，4 月 30 日 8 点 19 分 18 秒数据库尝试启动，但启动失败，报错原因为已有其他进程占用并启动了数据库实例。此后数据库一直无法正常拉起，直至 8 点 58 分服务器重启完成后，数据库才再次尝试启动并成功运行，实例角色为 standby、状态为 mount，随后在 8 点 58 分 53 秒顺利切换至 open 状态。

4、dw服务日志

    分析日志可知，4 月 30 日 08:19:18 守护进程（dw 服务）启动后，无法与 dmserver 数据库服务建立正常通信。此后守护进程持续反复尝试重启数据库实例服务，但始终通信异常、未能恢复。
    直至 08:56 分对服务器执行重启操作，08:58 分服务器重启完成后，dw 服务与 dmserver 通信链路恢复正常，顺利与 DM1 实例建立通信交互，集群各节点状态及服务运行全部恢复正常。

四、汇总分析

    经日志深度分析，4 月 30 日 08:19 备库 DM1 服务启动失败，核心原因是数据库启动检测到已有其他进程已占用并启动实例，导致本次自启流程冲突失败。
    从系统 message 日志时序来看，08:19 服务器刚完成上电开机，数据库本应由系统开机自启服务统一拉起，从理论时序和常规部署逻辑上，本不应存在第三方额外进程提前启动数据库的情况。
    针对这一异常进程抢占冲突问题，需进一步逐条梳理分析 message 系统日志，核查服务器整机启动流程、系统服务加载顺序、自启任务及后台进程拉起时序，排查是否存在多套自启配置、定时任务或残留僵死进程抢占实例端口与资源，造成数据库正常自启互斥失败。

    通过日志发现系统除了 DmServerDM1外还有一个 DmServiceDMSERVER 且8点19分两个服务均启动失败，怀疑是同一个数据库注册了多个服务导致的启动冲突。查看 8点58分服务器启动情况进一步验证

    从系统日志可明确确认：服务器开机时同时启动了 DmAPService、DmWatcherServiceDM1、DmServiceDM1 和 DmServiceDMSERVER 四个服务。其中 DmServiceDM1 启动时报无法创建 PID 文件错误，最终因DmServiceDMSERVER 与 DmServiceDM1 指向同一个数据库实例，引发端口、进程、文件资源互斥抢占，直接导致数据库启动冲突失败。其余三个服务正常启动后，数据库才得以恢复运行。
    最终判定：同一数据库实例被重复注册为多个系统服务，是本次备机开机启动失败的根本原因。
    解决方案：
    使用达梦官方服务卸载脚本，删除冗余服务，仅保留业务专用的 DmServiceDM1 即可彻底解决冲突：
    $DM_HOME/script/root/dm_service_uninstaller.sh -n DmServiceDMSERVER
    卸载完成后，服务器开机仅启动单一数据库服务，启动冲突问题完全解决，集群可正常自启动。