异常处理 - 负载异常处理 - 《OceanBase v2.2.30 官方教程》

异常现象
目标服务器压力确认
目标租户压力确认
目标集群压力确认
解决及避免办法

异常现象

当 OceanBase 集群内出现负载异常时，部分 OBServer 节点上 CPU 平均负载会出现异常，超过 OCP 正常告警阈值时会触发 OCP ，告警信息如下图所示：

遇到上述告警信息时一般需要先登录 OCP 从监控菜单中进入 OB 数据趋势 界面中查询性能监控以进行确认。确认顺序为：

目标服务器维度确认。
目标租户维度确认。
目标集群维度确认。

目标服务器压力确认

登录 OCP 后，从监控菜单中进入 OB 数据趋势 界面中，选择目标集群组、目标集群、目标 Server 和对应时间范围后点击搜索按钮，详细操作信息，请参见本手册性能监控内的内容。在性能趋势界面下方搜索到的指标中关注：QPS、QPS_RT、TPS、TPS_RT 和 CPUPERCENT 这四个指标，并找到告警对应时间点，确认告警是否符合预期。一般负载异常可能包含以下几种对应监控指标变化情况：

QPS、QPS_RT、TPS_RT 和 CPUPERCENT 在告警时间范围存在升高尖刺。当 TPS 变化不大，时间轴上 QPS 与 QPS_RT 尖刺发生较其他指标略早时，这种情况通常是由查询压力增大或 SQL 中存在烂 SQL 引起的，需使用 OCP 监控中的 Slow**SQL** 功能对具体集群中目标 Server上的慢查询进行排查。
QPS_RT、TPS、TPS_RT 和 CPUPERCENT 在告警时间范围存在升高尖刺。当 QPS 变化不大，时间轴上 TPQ 与 TPS_RT 尖刺发生较其他指标略早时，这种情况通常是由于写入压力增大引起，需使用 OCP 监控中的 Slo**wSQL** 功能对具体集群中目标 Server 上执行的事务进行确认。

目标租户压力确认

在使用 OCP 租户监控查询租户压力指标之前，需要先登录 sys 租户，通过下面的 SQL 确认目标服务器涉及租户，注意语句中的版本差异：

(1.x) obclient> SELECT zone,tenant_id, COUNT(1) cnt FROM __all_meta_table WHERE svr_ip = 'xxx.xxx.xxx.xxx' GROUP BY tenant_id ORDER BY zone,cnt DESC;
(2.x) obclient> SELECT zone,tenant_id, COUNT(1) cnt FROM __all_virtual_meta_table WHERE svr_ip = 'xxx.xxx.xxx.xxx'  GROUP BY tenant_id ORDER BY zone,cnt DESC;

拿到目标租户的 ID 后，通过下面的 SQL 语句查询到目标租户名称：

obclient> SELECT tenant_name FROM __all_tenant WHERE tenant_id IN (xxx,xxx);

之后进入 OCP，从监控菜单中进入 OB 数据趋势 界面中，选择目标集群组、目标集群、对应时间范围后单击搜索，详细操作信息，请参见性能监控章节。在性能趋势界面下方租户页签中找到目标租户，在目标租户性能趋势界面中的指标中关注：QPS、QPS_RT、TPS、TPS_RT 和 CPUPERCEN 这四个指标，并找到告警对应时间点，确认是否符合预期。一般负载异常时，目标租户级别监控指标变化情况可能包括以下几种情况：

QPS、QPS_RT、TPS、TPS_RT 和 CPUPERCENT 四个指标在告警监控时间范围内存在升高趋势，变化趋势上与目标服务器节点级别同时间的监控指标对应。这种情况下，说明租户读写压力较之前有增长，需联系业务人员进行行为确认。如确定读写压力是正常增长，则需对受影响租户进行扩容。详细操作信息，请参见租户管理章节。
QPS、QPS_RT、TPS、TPS_RT 和 CPUPERCENT 四个指标在告警时间范围内存在升高趋势，但变化趋势较目标服务器级别同时间的监控指标趋势明显小。在这种情况下，说明租户读写压力较之前略有增长，但集群整体压力增长不明显，主要还是租户或服务器增长比较明显，需要对租户的 Primary Zone 进行合理配置。

目标集群压力确认

进入 OCP，从监控菜单中进入 OB 数据趋势 界面中，选择目标集群组、目标集群、对应时间范围后单击搜索，详细操作信息，请参见性能监控章节。在性能趋势界面下方搜索到的指标中关注：QPS、QPS_RT、TPS、TPS_RT 和 CPUPERCEN 这四个指标，并找到告警对应时间点，确认是否符合预期。一般负载异常时，集群级别监控指标变化情况可能包括以下几种情况：

QPS、QPS_RT、TPS、TPS_RT 和 CPUPERCENT 四个指标在告警时间范围内存在升高趋势，变化趋势上与目标服务器级别同时间的监控指标对应。在这种情况下，说明集群读写压力较之前有增长，需联系业务人员进行行为确认。如确认为读写压力正常增长，需先对集群进行 OBServer 进行扩容，详细操作信息，请参见 OBServer 管理章节。完成集群扩容后再对受影响租户进行扩容，详细操作信息，请参见租户管理章节。
QPS、QPS_RT、TPS、TPS_RT 和 CPUPERCENT 这四个指标在告警时间范围内存在升高趋势，但变化趋势较目标服务器级别同时间的监控指标趋势明显小。在这种情况下，说明集群读写压力较之前略有增长，但集群整体压力增长不明显，主要还是租户或服务器增长比较明显，需要对租户的 Primary Zone 进行合理配置或考虑对目标租户进行扩容。

解决及避免办法

通过对目标服务器、租户和集群的压力确认，基本上可以定位引起负载异常的原因。总结起来一般有烂 SQL、租户 Primary Zone 配置不当和业务压力正常增长这三种原因，针对不同的原因有不同的解决和避免的办法。

烂 SQL

如负载异常原因为烂 SQL 导致，需要通过对烂 SQL 进行优化处理，紧急情况下可使用 OUTLINE 限流或直接联系业务人员限制烂 SQL 的执行。为长期避免此类问题，管理上可针对新上线的 SQL 进行性能审核，并周期性地进行 OCP SlowSQL 巡检。

租户 Primary Zone 配置不当

如负载异常原因为租户 Primary Zone 配置不当，可先对租户当前的 Leader 分布进行确认，具体 SQL 语句如下所示：

(1.x) obclient> SELECT zone,svr_ip,COUNT(1) cnt FROM __all_meta_table WHERE tenant_id = xxxx AND role =1 GROUP BY svr_ip ORDER BY zone,cnt desc;
(2.x) obclient> SELECT zone,svr_ip,COUNT(1) cnt FROM __all_virtual_meta_table WHERE tenant_id = xxxx AND role =1 GROUP BY svr_ip;
obclient> SELECT tenant_id,primary_zone FROM __all_tenant;

通过租户分布查询，确认当前租户的 Leader 分布是否为预期的 Zone，如果业务使用了分区表且支持 Leader 打散，可通过租户切主，将 Primary Zone 设置为可使用的所有 Zone，详细操作信息，请参见租户管理章节。配置租户 Primary Zone 前需通过以下语句确认集群自动均衡参数是否设置为 True：

obclient> SHOW PARAMETERS LIKE 'enable_rebalance';
-- 返回为 True 即为打开，否则需将其设置为 True
obclient> ALTER SYSTEM SET enable_rebalance = 'True';

租户打散是将 Primary Zone 设置到可选择 Zone 上，不同 Zone 之间用逗号分隔开，示例语句如下所示：

obclient> ALTER TENANT tenant_name primary_zone="zone1,zone2,zone3";

租户切主是将 Primary Zone 从某个 Zone 上设置到另一个 Zone 上，示例语句如下所示：

-- 假设之前的 Primary Zone 为 Zone2;
obclient> ALTER TENANT tenant_name primary_zone="zone2";

当 OceanBase 集群内存在多租户共享集群资源时，建议将不同租户的 Leader 设置到不同的 Zone 上，避免租户间相互影响。

业务压力正常增长

如负载异常原因为业务压力正常增长，需要针对当前集群资源使用情况，对租户进行扩容，详细操作信息，请参见租户管理章节。但如果集群中资源已经使用饱和，则需要先对集群进行扩容，详细操作信息，请参见 OBServer 管理章节。

只有在业务租户使用了 OceanBase 分区表，且租户 Primary Zone 打散到了所有 Zone 上时，扩容操作带来的性能增长才会呈现出线性增长趋势。比如 1-1-1 的集群扩容到 2-2-2 的集群，性能容量提升约为 50%。但如果业务使用的是单表，且租户 Primary Zone 仅设置了一个 Zone 时，扩容操作带来的性能增长并不是线性的，此时集群的压力分布取决于不同单表 Leader 上的读写压力大小，此时合理配置 Primary Zone，将不同单表的 Leader 分布到不同 Zone 中，可在一定范围内提示集群性能。