OceanBase数据库：SYS租户不可用，如何处理？

本文转自公众号：忙碌了两个小时的陈师傅

一、SYS租户简介

Oceanbase分布式数据库在创建集群后，默认会创建一个资源很小的SYS租户，SYS租户管控整个集群中多个租户，集群的管理也会通过SYS租户获取多个租户的元数据信息，当SYS租户不可用或SYS租户资源不足时会导致整个集群出现各种异常问题，同时集群中的所有租户都会受到影响，可见SYS租户对于集群来说也是很重要的，不要忽视对SYS租户的关注，当然不是所有集群中的SYS租户都会出问题，但有些部分特殊场景会触发一些SYS租户不可用的问题，例如：业务租户的资源变更。

二、环境描述

集群架构：5-5-5

集群租户数量：25

SYS租户资源配置：8C32G

故障业务租户资源配置：2C8G

Oceanbase分布式数据库版本：4.2.1.8

三、SYS租户不可用

日常维护打开OCP时，整个集群的运行状态是正常的，查看告警中心看到告警信息如下：

No memory or reach tenant memory limit.*[OOPS]=，错误码=4013，[T0] [lt=0][errcode=-4013] No memory or reach tenant memory limit([OOPS]=“alloc failed reason”, msg=tenant memory has reached the upper limit(tenant_id: 1021, tenant_hold: 1284046848, tenant_limit: 1285370675, alloc_size: 2097152))

报错信息中是业务租户（tenant_id: 1022）的META租户 tenant_id: 1021 内存不足达到上限，怎么会报 [T0] 租户的告警呢？查看集群中SYS租户的资源配置，是否因为SYS租户资源不足导致的告警呢？查看SYS租户资源时，发现SYS租户的状态为不可用，那么紧急增加SYS租户的资源配置，由8C32G调整为8C64G，发现调整SYS租户资源配置任务报错无法执行。查看其他业务租户的状态，发现均正常，唯有SYS租户状态不可用，同时也未收到业务部门的问题反馈。登录SYS租户的黑屏窗口，通过 DBA_OB_TENANTS 查看 SYS 租户相关的信息执行SQL语句时，均返回SQL错误：No memory or reach tenant memory limit。

四、分析处理过程

1. 排查是否因为SYS租户内存不足

SELECT T.TENANT_ID    ,T.SVR_IP    ,T.CTX_NAME    ,SUM(T.HOLD)/1024/1024/1024    ,SUM(T.USED)/1024/1024/1024    FROM OCEANBASE.GV$OB_MEMORY TWHERE T.TENANT_ID = 1AND T.SVR_IP = '1.0.0.1'GROUP BY T.TENANT_ID,T.SVR_IP,T.CTX_NAME;

查看SYS租户的内存被哪些内存上下文使用，查询结果KVSTORE_CACHE_ID KV缓存持有的内存很多，但实际使用的内存很少，同时查看MEMSTORE的内存使用率为5%，说明SYS租户的内存是充足的，并未达到满内存的状态。

2. 刷新SYS租户的KVCACHE和PLAN CACHE

SQL无法执行怀疑是否PLAN CACHE 缓存满了，刷新缓存试下

ALTER SYSTEM FLUSH KVCACHE TENANT = sys;ALTER SYSTEM FLUSH PLAN CACHE TENANT = sys;

缓存刷新后，发现问题依然存在。

3. 查看OBServer关于SYS租户的日志信息

关于T0和T1的日志，无法判断问题，相关报错的文档也没有。

sock has error ;write response fail;failed rto flush_buffer ;response rpc result fail ;

4. 查看论坛SYS租户不可用的相关报错信息，发现问题的可能原因

问题描述：当业务租户异常时，在系统（sys）租户下执行视图查询操作可能因超时而失败。这是因为视图的部分数据物理存储在业务租户中，当业务租户不可用时，相关数据无法正常获取，导致查询过程超时。

问题影响：OCP（OceanBase Control Platform）在同步租户信息时，通常通过系统租户查询业务租户信息。当这种查询因业务租户问题而超时后，OCP会误判系统租户本身已发生故障，从而错误地将系统租户标记为不可用状态。

问题解决：升级OCP 至4.4.0 可以解决大部分类似问题。后续OB会和OCP 配合整改全面解决本问题。

通过上述的描述，联想到OCP中SYS租户的告警信息中包含业务租户的内存不足，大概也猜到了问题的原因，此时需要登录到业务租户的SYS用户，查看内存相关的信息，看看是否因为内存不足导致的问题，登录后发现，执行任何SQL都会返回No memory or reach tenant memory limit 的SQL错误，无法查到任何的有用信息。通过 OB_ALLOCATE_MEMORY_FAILED 关键字查看OBServer日志中关于业务租户（tenant_id: 1022）的META租户 tenant_id: 1021的相关日志信息时，发现很多内存不足的报错。前两天因为这个业务租户要下线，由于无法直接删除租户，需要先做资源回收，将64C256G内存的租户调小资源为2C8G后，等待回收的时间段出现的内存不足问题。

思考：在OCP中 SYS 租户的状态为不可用，所以无法在OCP中修改租户资源配置和参数。业务租户内存不足，导致查询和维护的SQL均不能正常执行，合并和转储可能也延时了，集群中有很多其他租户正常运行，又不能重启机器和集群，停了又担心无法启动，应该如何在线调整解决这个问题呢？

解决方法：

1. 使用obclient 登录到sys租户，通过3个视图来查看资源单元信息

DBA_OB_UNITS (TENANT_ID)DBA_OB_RESOURCE_POOLS (TENANT_ID)DBA_OB_UNIT_CONFIGS (DBA_OB_UNITS.UNIT_CONFIG_ID) 获取 UNIT NAME

2. 直接修改业务租户资源单元的大小，注意3个zone都要修改

ALTER RESOURCE UNIT (上面查询的UNIT NAME) MEMORY_ZISE '32G';ALTER RESOURCE UNIT (上面查询的UNIT NAME) MEMORY_ZISE '32G';ALTER RESOURCE UNIT (上面查询的UNIT NAME) MEMORY_ZISE '32G';

修改之后，在OCP中查看该租户的配置，配置已经更新，一些常用的维护操作已恢复。等2分钟刷新SYS租户的状态，发现SYS租户状态已正常。

注意：通过后台修改的资源单元配置，只修改了内存，其他的配置均未修改，如日志盘大小，需要通过OCP再次修改该业务租户的资源配置为8C64G ，租户规格相关的配置会一同修改。租户的状态恢复后，如果有租户长时间未冻结的告警，要先做一下业务租户的合并。

五、总结

业务租户内存不足，为什么会导致SYS租户的状态不可用呢？是因为SYS租户定时要取业务租户的相关元信息，当查询问题租户时，由于问题租户执行任何SQL都会返回报错，同样这个报错也会返回给SYS租户，OCP收到报错后认为SYS租户在执行这个SQL时出现了报错，就会误报SYS租户的状态不可用，同时在SYS租户中所有涉及问题租户相关元信息的查询时，SYS租户都会返回 No memory or reach tenant memory limit 的SQL错误，即使查询的不是问题租户。可见业务租户异常对OCP来说不仅仅是误报，对SYS租户的影响还是存在的，所以日常的维护要多关注SYS租户。

想了解更多干货，可通过下方扫码关注