服务器发生了掉电、操作系统故障、网络故障等非数据库故障时，会对数据库和业务运行产生影响。此节介绍故障服务器上如果同时部署了CN和DN的情况下该如何处理以把对业务的影响降到最低。

• 隔离故障服务器。

  故障服务器上部署有CN，如果已开启CN自动剔除功能，10分钟内故障服务器未自动恢复，GaussDB 200会自动将故障CN剔除，以不影响DDL执行。

  • 如果集群部署和使用了负载均衡LVS，LVS会自动将连接切换到其他CN。用户只需重新执行失败作业并观察作业执行情况。预计影响业务时长：2分钟。
  • 如果没有部署和使用LVS，需要手动调整应用层的作业调度，将原来连接这个CN执行的作业切换到其他CN上执行。预计影响业务时长：18分钟。
    • 停止应用层的作业下发。
    • 停止数据库中的残留SQL。

      在各CN服务器上连接数据库，执行如下命令停止残留SQL。

      SELECT PG_TERMINATE_BACKEND(PID) FROM PG_STAT_ACTIVITY WHERE STATE='active' AND QUERY NOT LIKE '%TERMINATE%' AND APPLICATION_NAME NOT IN('JobScheduler','workload','WorkloadMonitor','cm_agent');

      返回t表示有残留SQL被停止。

       pg_terminate_backend
      ----------------------
       t
      (1 row)

    • 将应用连接切换到其他CN。具体方法请根据应用层的实现执行，此处不做说明。
    • 重新启动应用层的作业下发。

• 修复故障服务器。

  请根据故障服务器类型进行处理。操作系统故障定位手段和网络故障定位手段提供了部分故障处理和定位办法，可参考进行故障定位和恢复。同时建议您联系专业的操作系统和网络维护人员进行支撑。

  故障服务器修复后，使用ping命令，确认服务器是否可以成功连通。

• 加回故障服务器。
  • 故障服务器修复后，请按如下办法进行实例加回。预计影响业务时长：8分钟。
    • 以omm用户身份登录集群未故障的节点。执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。
    • 执行gs_om -t status --detail重新查看集群状态。此时故障服务器上整个集群的balanced状态为“No”；CN状态应该为Deleted；原始为主的DN，其状态应该为“Standby Normal”。

      

      

      服务器修复到修复完成期间，DN实例的状态演进正常为：Down->Starting->Standby Normal。CN的状态演进为：Down->Deleted。

      如果服务器修复后DN长时间（例如，3分钟）未切换成“Standby Normal”，请尝试使用gs_om -t start -h HOSTNAME启动故障节点上的GaussDB 200进程，然后重新查询集群状态。如果状态依然未变成“Standby Normal”，可以通过数据库故障定位手段中的办法确认服务器是否还存在其他问题。在这个过程中推荐联系技术支持工程师协助处理。

    • 停止应用层的作业下发，准备重置DN实例状态和恢复CN。
    • 停止数据库中的残留SQL。

      在各CN服务器上连接数据库，执行如下命令停止残留SQL。

      SELECT PG_TERMINATE_BACKEND(PID) FROM PG_STAT_ACTIVITY WHERE STATE='active' AND QUERY NOT LIKE '%TERMINATE%' AND APPLICATION_NAME NOT IN('JobScheduler','workload','WorkloadMonitor','cm_agent');

      返回t表示有残留SQL被停止。

       pg_terminate_backend
      ----------------------
       t
      (1 row)

    • 执行命令gs_om -t switch --reset重置DN实例状态。
      说明：

      switch为维护操作：确保集群状态正常，所有业务结束，并使用pgxc_get_senders_catchup_time()视图查询无主备追赶后，再进行switch操作。

      执行gs_om -t status --detail重新查看集群状态。集群balanced状态应该已恢复为“Yes”。如果未恢复，请尝试再次重置，并查看状态。依然无法恢复balanced状态时，可以尝试通过查看OM日志进行问题定位，并联系华为技术工程师协助处理。

    • 执行gs_replace命令尝试修复故障服务器上的CN实例。其中node2为故障服务器的hostname，请根据实际替换。关于故障实例修复的更多信息请参考修复MPPDBServer实例。

      执行如下命令进行实例配置。

      gs_replace -t config -h node2

      您会看到异常CN先被删除然后被重新配置。这个过程中CN状态会由“Deleted”变为“Down”。

      Fixing ETCD instances.
      Node is not installed etcd.
      Fixing all the CMAgents instances.
      There are [0] CMAgents need to be repaired in cluster.
      Configuring replacement instances.
      Successfully configured replacement instances.
      Successfully fixed all the CMAgents instances.
      Configuring
      Waiting for promote peer instances.
      .
      Successfully upgraded standby instances.
      Deleting failed CN from pgxc_node.
      Successfully deleted failed CN from pgxc_node.
      Dumping CN files from the Normal CN.
      Successfully dumped CN files from the Normal CN.
      Configuring replacement instances.
      Successfully configured replacement instances.
      Setting the SCTP.
      Successfully set the SCTP.
      Configuration succeeded.

      执行如下命令重启实例。这个过程中CN状态会由“Down”变为“Normal”。

      gs_replace -t start -h node2

      Starting.
      ======================================================================
      Successfully started instance process. Waiting to become Normal.
      ======================================================================
      .
      ======================================================================
      Start succeeded on all nodes.
      Start succeeded.

      如果尝试修复CN失败，请参考删除Coordinator实例和添加Coordinator实例，先删除CN，再重新增加CN。

    • 重新启动应用层的作业下发。
  • 故障服务器无法修复时，请更换服务器后，按如下步骤操作。预计影响业务时长：数据量相关，一般为1到4小时。
    • 停止应用层的作业下发，准备替换故障主机。
    • 停止数据库中的残留SQL。
    • 更换故障节点。
    • 重新启动应用层的作业下发。