数据库应急概述

广义上，不只是发生故障才需要应急响应，所有超出集群设计能力、规划预期的情况可能都需要紧急处理。应急事件处理的首要目的并不是排查根因，而是快速止血，先让集群尽快恢复正常服务能力。

问题发现渠道

应急事件的发现，通常分为主动发现和被动感知两类，一般分为以下几个渠道：

• 业务监控报警（应用层监控）

• 数据库日常巡检（详情请参见 监控和告警 章节的 监控 ）

• 数据库监控报警（详情请参见 监控和告警 章节的 告警 ）

应急事件分类

硬件&基础设施故障

通常由软硬件问题导致。其中多数单机问题 OceanBase 可以自行恢复，但是一些情况依然需要通过应急手段进行主动干预。常见的基础设施类故障分为以下几类：

• 服务器硬件故障导致的宕机

• 服务器 NTP 时钟偏移

• 机柜/机房级电力故障

• 单机网卡故障、或机柜/机房网络抖动等

• ODP 集群负载均衡设备故障

业务访问变化导致的容量不足

当业务层的访问量由于营销活动等原因突然上涨，或者有新业务发布上线时，往往可能导致数据库访问超过前期设计容量。此时就会表现为性能下降、响应时间变长、连接超时等一系列问题。对于 OceanBase，性能容量不足通常表现为以下几种情况：

• SQL 查询导致的集群资源占用率过高

• 集群节点磁盘 IO 过高

• 集群节点网卡负载过高

• 租户请求队列积压

• 租户内存写满

• ODP 线程满

• 集群节点日志盘空间满

• 集群节点数据盘空间满

OceanBase 集群的其他问题

除上述两大类情况意外，还有一类问题是在 OceanBase 的分布式架构下，一些特有的使用场景或用户习惯触发的问题。导致这些问题的原因多样，可能是业务的访问方式导致，少数情况下也可能是触发了软件bug，您可以使用一些通用的应急手段止血处理。这些问题一般包括：

• 租户转储卡住

• 集群冻结/合并卡住

• 悬挂事务&长事务

• sys 租户队列积压

• 节点进程异常退出

• 内部模块内存不足/泄漏

• buffer 表问题

上述三类问题，有些问题直接表现为"现象"，有些则是导致其他异常现象的原因。关于如何针对这些不同的应急场景进行正确的处理，请参见 分析诊断&决策流程。