目前可将网络、服务器和磁盘三方面的异常按影响范围从小到大可分为以下三类：

• 服务器故障

• 机房级故障

• 地域级故障

OceanBase 数据库在架构部署前，一般会针对不同级别的高可用需求提供不同级别的高可用架构方案。其中服务器级别高可用方案是由 OceanBase 数据库最小三副本的特性保障的，机房级别高可用方案一般是将不同的 Zone 部署在不同机房。地域级高可用则通过三地五中心架构或主备 OceanBase 数据库链路高可用架构去实现。针对不同高可用级别的架构，所采用异常处理方式也有所不同。

服务器故障

在 OceanBase 集群中，服务器故障是比较频发的一类故障，通常可简单分为服务器硬件异常和软件异常两类。硬件比较常见的有 CPU、存储硬件和网卡三类导致的异常，软件比较常见的有操作系统崩溃和 OceanBase 数据库依赖服务异常等问题。

由于 OceanBase 数据库天然的三副本架构，在处理此类异常时通常可根据异常节点数进行不同处理：

• 单节点异常：可以通过 STOP SERVER 命令将这个异常服务器停止掉。这样它的 IP 就不对外提供服务，后续还可以进行诊断、替换和维修等动作，这对线上环境的运维是一个非常有帮助的命令。需要注意的是 STOP SERVER 不会将 Server 进程停掉也不会将 Server 置于 Inactive 的状态。

  详细操作过程请参见 管理 OBServer 节点状态。

• 多节点异常：通常这类异常出现情况并不会太多，除了同一批硬件同时异常的情况。通常遇到此类问题时，需要先定位故障多节点分布情况，可通过 sys 租户中的 __all_server 表，根据不同故障节点的 IP 去定位故障节点是否属于同一个 Zone，如果故障节点同属于一个 Zone，可以通过 STOP Zone 命令将这个多个节点异常的 Zone 停止。这样这个 Zone 就不对外提供服务了，在应急情况下这个操作是非常有效的。同理，STOP Zone 操作不会将整个 Zone 内的进程停止，仅仅在 __all_server 表中标记停止时间。详细操作信息，请参见 启动或停止 Zone。

• 如果多个故障节点不属于同一个 Zone，此时需要根据 OceanBase 集群中存活副本数情况去判断是否采取扩容替换或使用备份恢复集群等停服务措施。

机房级故障

在拥有机房级容灾能力的 OceanBase 集群中，不同的 Zone 应该部署在不同的机房中，当某个机房发生故障时即可采用 Zone 管理操作进行流量切换，类似于服务器多节点异常情况的处理。目前比较常见的同城多机房容灾部署架构有同城三机房三/五副本架构，即同城三个机房分别部署三个 Zone 或以 2-2-1 的分布方式部署五个 Zone。此架构下 OceanBase 集群具有同城机房级容灾能力，不同机房间流量切换损耗几乎等于不同机房间的网络延迟。

还可部署同城双机房三/五副本架构，即同城两个机房，选择其中一个机房作为多数派 Zone 部署机房，另一个机房作为灾备机房部署少数派个副本。此架构下 OceanBase 集群同样具有同城机房级容灾能力，流量切换损耗也仅为机房间网络延迟，但只有在多数派其中一个副本异常时发生。

当某个机房发生故障时，用户可通过 STOP Zone 操作将异常 Zone 置于不对外提供服务的状态，在 IDC 恢复工作后再通过 START Zone 操作将 Zone 恢复正常。详细操作信息，请参见 启动或停止 Zone。

如果多个 IDC 发生异常，且故障副本数达到多数派，此时需要采取恢复备份等停服操作去恢复集群。

地域级故障

OceanBase 数据库目前常用的地域级容灾能力有两种：三地五中心和异地主备双链路。当 OceanBase 数据库出现地域级异常时，三地五中心架构可直接通过租户切主的方式，将租户的 Primary Zone 切至正常提供服务的地域。在异地主备双链路情况下，一般不同链路的 OceanBase 集群可通过 OceanBase 数据迁移服务（OMS）进行数据同步，当某个地域出现集群异常时，需要数据库与应用同时切至正常地域继续提供服务。

OceanBase 集群异常的处理逻辑总体来讲，就是利用 OceanBase 数据库多副本高可用特性，将正常的数据库访问流量通过管理操作切至正常副本，从而达到故障容灾的效果，以为管理员、运维同学和机房同学提供充足的时间去修复不同层级中实际发生的异常，保障数据服务不中断。