联系我们
18591797788
hubin@rlctech.com
北京市海淀区中关村南大街乙12号院天作国际B座1708室
18681942657
lvyuan@rlctech.com
上海市浦东新区商城路660号乐凯大厦26c-1
18049488781
xieyi@rlctech.com
广州市越秀区东风东路华宫大厦808号1608房
029-81109312
service@rlctech.com
西安市高新区天谷七路996号西安国家数字出版基地C座501

在企业级数据库运维中,租户不可用、内存异常飙升是足以让运维团队紧张的突发状况。近期我们处理了一起 OceanBase 集群故障,根源指向已知 bug,最终通过应急处理与版本升级彻底解决。今天就把完整排查过程、解决方案及避坑要点分享给大家。
项目组首先反馈测试租户 SQL 执行失败,登录对应的测试租户,查看memory_info表,发现当前租户的memstore爆掉。

集群出现不可用告警,sys租户页面也显示当前租户不可用,但是sys租户仍然可以登录。

并且有租户memstore限流,4013等告警。


重启当前节点后,登录sys租户排查其他节点内存情况,仍然有问题,ob_sql_phy_plan的mod内存使用仍然在不断增加且较高。


该现象和Unit迁移后plan cache内存泄漏的已知bug高度吻合。
登录sys租户,通过下面的sql排查当前集群有问题的机器
select distinct svr_ip from oceanbase.__all_virtual_memory_info where ctx_name='PLAN_CACHE_CTX_ID' and mod_name = 'OB_SQL_PHY_PLAN' and used>10000000000;

拉取所有环境的sys租户的连接串,排查有问题的集群。

将所有有问题节点,轮询重启后问题解决。
1.依次重启内存泄漏的observer
2.升级到问题修复的版本,3.2.3bp10(oceanbase-3.2.3.3-110000092023091219)之后的版本以修复该问题。
OceanBase官网对该问题的记录
https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000481973?back=kb
后续我们还会带来更多数据库实战技巧、性能调优干货,助力你的技术之路少走弯路。下次见!