与中国联通技术共建:通过obdiag分析OceanBase DDL中的报错场景

中国联通软件研究院(简称联通软研院)在全面评估与广泛调研后,在 2021年底决定采用OceanBase 作为基础,自研分布式数据库产品CUDB(即China Unicom Database,中国联通数据库)。目前,该分布式CUDB已在中国联通的338多个项目中顺利实施,助力完成了85TB的应用数据迁移,使慢SQL查询数量减少了43%,同时数据库运维效率的人均提升达到了20%。

为完善产品能力,支撑中国联通个性化的业务需求,联通软研院与OceanBase社区在数据库的内核和外围工具层面展开共建,比如事务日志解析LogMiner、敏捷诊断工具obdiag 等功能的深度共建,以及实现多个核心功能的研发,修复多个OceanBase内核BUG。其中,对于LogMiner的共建历程与经验已发文分享本文主要分享obdiag共建的技术背景、设计思路、实现细节及其带来的价值。

一、分布式CUDB演进历程

四年前,中国联通基于内部数据库系统的痛点与外部100%自研要求的背景,启动全栈分布式数据库建设。从替代高危 MySQL、降低商用依赖,以及提升中国联通软研院软实力等多方面考虑,选定基于国内开源分布式数据库产品OceanBase打造自研数据库产品分布式CUDB(详情见生产系统稳定上线600天 ------中国联通分布式 CUDB 的开源共建和规模化应用)。

对于分布式 CUDB 的演进历程,简言之,联通软研院在引进OceanBase的第一年着重于产品化建设。实现产品的一键开通、弹性扩缩、高效迁移,并且开始试点推广应用。2023年开始对接监控运维体系,并且开始大规模推广使用。重点聚焦数据库产品生态工具方面的补齐和人员能力的提升,为替代 MySQL 和新上应用提供全栈国产的数据库资源及服务能力。

虽然联通软研院做了很多产品能力建设,如高效的数据迁移、异地容灾高可用、完善的数据库自治服务、智能预测与诊断自愈,形成了相对完善的产品体系。但仍面临诸多挑战,比如现有功能不完全满足联通的个性化需求,再比如运维人员对数据库内核和源码的掌控不足,导致处理集群问题时非常棘手。

因此,在2024年,联通软研院推动智能化运维,着手智能运维建设。其中,为进一步提高自动化运维诊断效率,联通软研院与OceanBase携手合作,在OceanBase敏捷诊断工具obdiag的基础上进行深度共建,并深入内核研究,共同研发了一项全新的功能------建索引报错的根因分析功能。

、敏捷诊断工具obdiag共建背景

OceanBase是原生分布式数据库系统,故障根因分析通常是比较繁琐的,涉及的因素可能有很多,如机器环境、配置参数、运行负载等。专家在排查问题的时候需要获取大量的信息来分析故障。

那么,如何高效地获取故障场景下分散在各个节点的信息,挖掘其中的关联性,帮助用户自助诊断问题呢?

在引入obdiag前,每当遇到OceanBase数据库系统的复杂故障时,用户往往求助于原厂的专业团队。这不仅是因为故障排查涉及大量分布在不同节点上的信息,而且收集和整理这些信息缺乏统一的工具,再加上与专家反复沟通确认细节的过程,使整个故障解决周期变得漫长且充满变数。

拥有obdiag这一敏捷诊断工具后,通过obdiag的一键集群巡检、一键诊断分析、一键信息收集及一键根因分析功能,大大简化了故障排查的交互过程。即便是经验相对不足的技术人员也能够快速地识别出潜在问题,并根据诊断结果采取相应的措施,提升了故障排查工作的效率。

然而,obdiag现有的功能并不能满足联通软研院的故障排查需求。众所周知,在数据库运维中,DDL(Data Definition Language)操作是常见且重要的组成部分,其中包括创建、删除或修改数据库对象,比如表、索引等。但在实际生产环境中,DDL操作可能会因为各种原因失败,比如资源不足、并发冲突等,这会给业务带来不必要的中断和损失。为了解决这个问题,联通软研院基于obdiag框架进行了扩展,设计并实现了新的根因分析功能------建索引报错的根因分析。该功能能够在建索引失败时,像专家一样分析建索引失败的原因,给出分析报告。

三、建索引报错的根因分析

建索引报错的日志分析的基本思路是根据建索引的基本步骤,判断建索引失败在哪一步,然后决策收集哪些机器的日志。排查思路如下图所示。

排查共8个步骤。

第1步:租户名、数据库名、表名、创建索引失败的索引名字,作为输入参数。

第2步:根据入参,获取对应的tenant_id、database_id、table_id。

复制代码
# 获取租户id
 select tenant_id from __all_tenant where tenant_name = '租户名';
 # 获取数据库id
 select database_id from  __all_database  where database_name='数据库名';
 # 获取表id
 select table_id  from __all_virtual_table where table_name = '表名' and tenant_id = '租户id' and database_id='数据库id';  

第3步:根据索引名,获取索引表id。

复制代码
# 获取索引表id
 select table_id from __all_virtual_table_history where tenant_id = '租户id' and data_table_id = '数据库id' and table_name like '%索引名%';  

第4步:根据索引表ID,查询__all_virtual_ddl_error_message表格中是否有记录。

复制代码
# 获取task_id、trace_id
 select task_id ,trace_id from __all_virtual_ddl_error_message where tenant_id = '租户id' and object_id = '索引表id';  

如果无记录,那说明失败在发送RPC,打印出信息,提示此时需要人工接入排查,否则进入步骤5

第5步:根据task_id,查询__all_rootservice_event_history表。

复制代码
# 查询__all_rootservice_event_history表
 select event, value6,rs_svr_ip, rs_svr_port from __all_rootservice_event_history where value4 = 'task_id' and value2 != 0 and event != 'switch_state' and event not like 'index build task process fail' order by gmt_create desc limit 1;  

如果event字段的值为是ddl wait trans end ctx try_wait,那么进入第6步,如果是 index sstable build task finish,那么进入第7步,如果是其他的步骤,那么进入第8步。

第6步:event的名字为ddl wait trans end ctx try_wait,那么根据trace_id,去捞主表所有的tablet所在leader节点的日志。

第7步:event的名字为 index sstable build task finish,根据trace_id去捞取observer的日志。

第8步:event既不是ddl wait trans end ctx try_wait,也不是index sstable build task finish,此时需要根据trace_id去捞取rootservice.log.。

目前obdiag支持了增加索引时报错诊断场景,该支持适用于OceanBase 4.2.3 版本及OceanBase 4.3版本以上。

复制代码
obdiag rca run --scene=index_ddl_error --input_parameters='{"tenant_name":"cudb_test","table_name":"test1245","database_name":"test","index_name":"idx_name"}' -c obce423config.yml  

input_patameters是一个用于输入不同根因分析场景下需要引入的变量赋值,输入对象的应该为一个json格式的字符串用于解析。

复制代码
tenant_name:租户名table_name:表名database_name:库名index_name:索引名  

示例:如下为一次调用的结果record的展示。

总结

联通软研院与OceanBase的合作不仅是技术上的交流,更是对未来发展趋势的一种探索。通过共建obdiag的新功能,双方旨在达成四个目标。

· 提升运维效率:通过自动化的故障诊断,减少人工介入的时间成本,提升整体运维效率。

· 增强系统稳定性:及时发现并解决问题,提高数据库系统的稳定性和可靠性。

· 促进技术创新:借助双方的技术积累,共同探索数据库领域的前沿技术,推动技术创新。

· 增强用户体验:为用户提供更可靠、更高效的数据库服务,提高用户满意度。

在此过程中,特别感谢OceanBase谢振江(花名:仓氐)提供的排查思路及流程,以及中国联通软件研究院靖永栋提供根因分析场景编码实现。

附录

OceanBase GitHub仓库: GitHub - oceanbase/oceanbase: OceanBase is an enterprise distributed relational database with high availability, high performance, horizontal scalability, and compatibility with SQL standards.

感兴趣的DBA和开发者可以加入obdiag SIG进行共建开发。

obdiag 下载地址: https://www.oceanbase.com/softwarecenter

obdiag 官方文档: https://www.oceanbase.com/docs/obdiag-cn

obdiag github地址: GitHub - oceanbase/obdiag: obdiag (OceanBase Diagnostic Tool) is designed to help OceanBase users quickly gather necessary information and analyze the root cause of the problem.

obdiag SIG 营地: [obdiag SIG] 诊断工具组 · OceanBase 技术交流

相关推荐
DisonTangor1 天前
DeepSeek-OCR 2: 视觉因果流
人工智能·开源·aigc·ocr·deepseek
数智联AI团队1 天前
AI搜索引领开源大模型新浪潮,技术创新重塑信息检索未来格局
人工智能·开源
朝风工作室1 天前
开源一款轻量级跨网段 IPC 设备发现与网络配置工具
网络·开源
OceanBase数据库官方博客1 天前
滔搏基于OceanBase实现 15TB到0.9TB“无痛切换”与“系统瘦身”
数据库·oceanbase·分布式数据库
OceanBase数据库官方博客1 天前
爱奇艺基于OceanBase实现百亿级卡券业务的“单库双擎”架构升级
数据库·架构·oceanbase·分布式数据库
LitchiCheng1 天前
Mujoco 开源机械臂 RL 强化学习避障、绕障
人工智能·python·开源
我送炭你添花1 天前
开源TR-069 ACS(自动配置服务器)GenieACS 的四个主要模块详细介绍
运维·服务器·开源
冬奇Lab1 天前
一天一个开源项目(第9篇):NexaSDK - 跨平台设备端 AI 运行时,让前沿模型在本地运行
人工智能·开源
FIT2CLOUD飞致云1 天前
飞致云开源社区月度动态报告(2026年1月)
开源·飞致云·月度报告·开源日报
江湖有缘2 天前
基于华为openEuler部署EspoCRM开源客户关系管理平台
开源