节点宕机

当数据库因为硬件问题导致服务异常，且出现节点宕机时，需要对故障机器采取应急措施。本文主要介绍节点宕机的应急处理方法。

应急处理方法

• 对于已知的机器硬件故障，应直接替换故障机器。

  首先要确保集群中有足够的冗余资源（OBServer机器），可以代替故障节点进行工作。具体操作请参见 替换 observer。

• 非硬件故障，未知原因的 observer 进程退出。

  对于这类场景，比如 core dump 场景，应急处理办法也是先尝试拉起恢复。如果无法恢复，请参见 observer 进程异常退出 进行详细排查。

对于无法第一时间确认是否因硬件故障导致的节点宕机（例如网络抖动、掉电等其他原因），此时用户可能希望不是立即替换该节点，而是修复其他问题后再次尝试拉起 observer，此时需要注意server_permanent_offline_time 参数的设置。在 OceanBase 数据库中，server_permanent_offline_time 配置项的名称为"永久下线时长"，是用来控制"集群中某个节点不可用多长时间后，OceanBase 将其踢出成员列表"。例如，假设某个 OB 集群中 server_permanent_offline_time 的值为 2h，那么意味着当某台节点宕机后，在 2 小时内如果可以恢复，那么拉起后的 OB 节点数据依然有效，只需追平宕机期间落后的增量数据即可。但是如果宕机超过 2 小时，那么节点再次拉起后，节点中的所有副本都会被清空（被 RS 踢出 Paxos 成员列表），其上的全部数据都需要从其他副本重新拉取。