OceanBase 分布式数据库运维实战完整指南5步定位 SQL 延迟飙高与 Core Dump 根因【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase凌晨三点告警群炸了生产 OceanBase 分布式数据库延迟突然飙高慢查询排队业务方每十分钟催一次。你登上 observer 服务器面对一个占了几 GB 内存的 C 进程脑子里只有一个问题从哪查起这篇文章带你走一遍 OceanBase 数据库的完整排障流程——日志分析、trace id 关联、core dump 分析、debug sync全部命令都可以照抄目标是 30 分钟内从告警走到根因。为什么值得看OceanBase 是基于 Paxos 共识协议的分布式关系型数据库官方给出的指标是 RPO 0零数据丢失、RTO 8 秒已服务 2000 多家客户单集群支持超 1500 节点。规模越大出事了往哪查就越值钱。分布式数据库的难点不在写 SQL而在排障一个请求可能横跨多个节点一份日志里几百个字段。这个仓库自带了完整的调试体系——trace 机制、日志限流参数、debug sync、离线工具集并且都写进了文档不用去猜。把这套流程练熟之后下次告警进来你打开终端第一反应不是看看而是敲命令。上图是官方架构文档里的集群视图集群按 Zone可用区划分Zone 里跑 observer 进程数据按分区Partition水平拆成 Tablet多副本通过日志流Log Stream做 Paxos 复制。排障时记住这个层级先定位是哪个租户、哪个节点、哪条 SQL再决定往日志还是往 core 走。核心能力拆解先给一张排障路径图后面每个小节对应图里的一步5 分钟拉起一个可复现问题的集群能做什么排障第一步永远是能不能在本地复现。不用理解多租户和资源单元一条 docker 命令起个实例。怎么做拉镜像跑 mini 模式实例2881 是 MySQL 协议端口客户端就连接它。关键参数MODEmini控制实例规格。# 部署 mini 模式实例暴露 MySQL 协议端口 2881 docker run -p 2881:2881 --name oceanbase-ce -e MODEmini -d oceanbase/oceanbase-ce # 连接系统租户 sys docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -urootTrace ID 关联日志把一次请求的所有痕迹串起来能做什么OceanBase 里每条 SQL 请求都有唯一 trace id就像快递单号拿着它能捞出这条请求在集群里留下的全部日志。怎么做复现慢 SQL 后马上取 trace id再去运行目录的log/子目录 grep。一条日志包含时间戳、级别、模块、函数名、文件行号、线程、trace id 等字段grep 时优先用 trace id其次用模块名如[SQL.EXE]。-- 取上一条 SQL 请求的 trace id select last_trace_id(); -- 把日志级别临时调到 DEBUG扩大抓取范围 set ob_log_leveldebug; -- 日志找不到时先放宽限流再去找 alter system set syslog_io_bandwidth_limit1G; alter system set diag_syslog_per_error_limit1000;⚠️ob_log_leveldebug会让日志量暴涨磁盘和性能都会受伤生产上查完立刻调回别挂着过夜。show trace把一条 SQL 的耗时拆成树能做什么日志告诉你发生了什么show trace告诉你时间花在哪。输出是一棵耗时树sql_compile硬解析下的 parse/resolve/rewrite/optimize/code_generate和sql_executeopen/response_result/close。看到hard_parse占大头就往执行计划方向查看到response_result慢大概率是数据量大或网络回传问题。怎么做4.x 版本先开 trace跑目标 SQL再show trace看结果。-- 4.x 开启 trace 功能 set ob_enable_show_trace1; select * from t, t1 where t.id t1.id; -- 查看各阶段耗时树 show trace;Core Dump 分析加载 observer.debug 让 gdb 开口说话能做什么进程挂了或者想 attach 活进程看调用栈但 RPM 安装的 observer 是剥离了调试符号的直接bt只有地址没有源码行。怎么做先用observer -V拿 REVISION 的前半部分去对应的 RPM 仓库找 debuginfo 包解压后用 gdb 的symbol-file加载之后bt就能看到文件路径和行号。# 1. 查版本动态库路径没配好时先补 LD_LIBRARY_PATH LD_LIBRARY_PATH../lib:$LD_LIBRARY_PATH ./observer -V # 2. 从 RPM 中解出 observer.debug rpm2cpio oceanbase-ce-debuginfo-4.1.0.1-102000042023061314.el7.x86_64.rpm | cpio -div # 3. gdb attach 进程或直接打开 coredump 文件加载符号后看栈 gdb ./observer $(pidof observer) (gdb) symbol-file usr/lib/debug/home/admin/oceanbase/bin/observer.debug (gdb) bt日志里打印的lbt()调用栈是一串地址用addr2line -pCfe ./bin/observer 0x...也能翻成函数和源码行这条路径在 调试文档里有完整示例。Debug Sync在生产环境冻结指定线程能做什么gdb attach 会挂起整个进程而 OceanBase 靠心跳维持活性硬挂可能把集群搞出二次故障。debug sync 让特定线程停在代码指定点你随便看现场看完发信号它再继续。怎么做先把debug_sync_timeout设为非 0 打开开关再设置挂起点调完唤醒并清理。-- 打开 debug sync 开关非 0 即开启 alter system set debug_sync_timeout100000s; -- 让线程在指定点挂起等待信号 set ob_global_debug_sync BEFORE_UNIT_MANAGER_LOAD wait_for signal_name execute 10000; -- 现场看完后唤醒 set ob_global_debug_sync now signal signal_name; -- 收尾关闭开关别留在生产里 alter system set debug_sync_timeout0;⚠️ debug sync 在 release 模式下同样生效也就是说生产环境默认就开着这个能力——用完后一定要执行最后两条清理否则别人连进来会踩到你留下的挂起点。踩坑实录坑 1./observer -V报error while loading shared libraries: libmariadb.so.3→ 根因observer 依赖的动态库在旁边的lib/目录里当前进程的库搜索路径没包含它。 → 修复LD_LIBRARY_PATH../lib:$LD_LIBRARY_PATH ./observer -V之后所有手动执行 observer 的操作都带上这个前缀。坑 2gdb 里bt打出来的全是匿名地址没有文件名和参数→ 根因RPM 装的 observer 剥离了调试符号符号在独立的 debuginfo 包里不加载等于盲打。 → 修复按上一节流程解出observer.debug在 gdb 里执行symbol-file /全路径/observer.debug再bt。坑 3日志级别已经 DEBUG想要的日志还是搜不到→ 根因不是没打是被限流丢了。同一个错误超过diag_syslog_per_error_limit条后就不再输出日志写带宽也会撞syslog_io_bandwidth_limit。 → 修复alter system set diag_syslog_per_error_limit1000;和alter system set syslog_io_bandwidth_limit1G;⚠️ 所以搜不到日志别先怀疑自己拼错了 grep。坑 4gdb attach 之后集群心跳超时告警反而更多了→ 根因gdb 挂起的是整个进程多租户 observer 里几百个线程全停心跳、选举保活都断了。官方文档明确建议单线程场景才用 gdb否则优先日志或 debug sync。 → 修复改用 debug sync 只挂目标线程alter system set debug_sync_timeout100000s;配合上一节的挂起/唤醒命令操作。延伸方向本地开发环境IDE 连接远程机器、C 插件配置见 IDE 配置。单元测试用 googletest 写test_xxx.cpp并接入 CMake流程见 单元测试指南CI 跑法长这样SQL 审计分析用仓库自带的 审计脚本 对审计日志做定期归档和统计分析。离线运维备份恢复、日志流工具等底层操作见 ob_admin 工具集。速查表参数 / 命令设置方式建议值作用ob_log_levelset ob_log_leveldebug;生产 info排查期 debug会话级日志级别syslog_io_bandwidth_limitalter system set ...1G日志写带宽上限diag_syslog_per_error_limitalter system set ...1000同一错误最大输出条数enable_async_syslogalter system set ...False;排查期 False改同步打印日志防丢debug_sync_timeoutalter system set ...默认 0关闭排查期100000sdebug sync 总开关last_trace_id()select last_trace_id();—取上一条 SQL 的 trace id先把上面的命令在测试机里按顺序跑一遍docker 起实例、取一次last_trace_id、看一次show trace。有输出了再来说哪里卡住了。【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OceanBase 分布式数据库运维实战完整指南：5步定位 SQL 延迟飙高与 Core Dump 根因
OceanBase 分布式数据库运维实战完整指南5步定位 SQL 延迟飙高与 Core Dump 根因【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase凌晨三点告警群炸了生产 OceanBase 分布式数据库延迟突然飙高慢查询排队业务方每十分钟催一次。你登上 observer 服务器面对一个占了几 GB 内存的 C 进程脑子里只有一个问题从哪查起这篇文章带你走一遍 OceanBase 数据库的完整排障流程——日志分析、trace id 关联、core dump 分析、debug sync全部命令都可以照抄目标是 30 分钟内从告警走到根因。为什么值得看OceanBase 是基于 Paxos 共识协议的分布式关系型数据库官方给出的指标是 RPO 0零数据丢失、RTO 8 秒已服务 2000 多家客户单集群支持超 1500 节点。规模越大出事了往哪查就越值钱。分布式数据库的难点不在写 SQL而在排障一个请求可能横跨多个节点一份日志里几百个字段。这个仓库自带了完整的调试体系——trace 机制、日志限流参数、debug sync、离线工具集并且都写进了文档不用去猜。把这套流程练熟之后下次告警进来你打开终端第一反应不是看看而是敲命令。上图是官方架构文档里的集群视图集群按 Zone可用区划分Zone 里跑 observer 进程数据按分区Partition水平拆成 Tablet多副本通过日志流Log Stream做 Paxos 复制。排障时记住这个层级先定位是哪个租户、哪个节点、哪条 SQL再决定往日志还是往 core 走。核心能力拆解先给一张排障路径图后面每个小节对应图里的一步5 分钟拉起一个可复现问题的集群能做什么排障第一步永远是能不能在本地复现。不用理解多租户和资源单元一条 docker 命令起个实例。怎么做拉镜像跑 mini 模式实例2881 是 MySQL 协议端口客户端就连接它。关键参数MODEmini控制实例规格。# 部署 mini 模式实例暴露 MySQL 协议端口 2881 docker run -p 2881:2881 --name oceanbase-ce -e MODEmini -d oceanbase/oceanbase-ce # 连接系统租户 sys docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -urootTrace ID 关联日志把一次请求的所有痕迹串起来能做什么OceanBase 里每条 SQL 请求都有唯一 trace id就像快递单号拿着它能捞出这条请求在集群里留下的全部日志。怎么做复现慢 SQL 后马上取 trace id再去运行目录的log/子目录 grep。一条日志包含时间戳、级别、模块、函数名、文件行号、线程、trace id 等字段grep 时优先用 trace id其次用模块名如[SQL.EXE]。-- 取上一条 SQL 请求的 trace id select last_trace_id(); -- 把日志级别临时调到 DEBUG扩大抓取范围 set ob_log_leveldebug; -- 日志找不到时先放宽限流再去找 alter system set syslog_io_bandwidth_limit1G; alter system set diag_syslog_per_error_limit1000;⚠️ob_log_leveldebug会让日志量暴涨磁盘和性能都会受伤生产上查完立刻调回别挂着过夜。show trace把一条 SQL 的耗时拆成树能做什么日志告诉你发生了什么show trace告诉你时间花在哪。输出是一棵耗时树sql_compile硬解析下的 parse/resolve/rewrite/optimize/code_generate和sql_executeopen/response_result/close。看到hard_parse占大头就往执行计划方向查看到response_result慢大概率是数据量大或网络回传问题。怎么做4.x 版本先开 trace跑目标 SQL再show trace看结果。-- 4.x 开启 trace 功能 set ob_enable_show_trace1; select * from t, t1 where t.id t1.id; -- 查看各阶段耗时树 show trace;Core Dump 分析加载 observer.debug 让 gdb 开口说话能做什么进程挂了或者想 attach 活进程看调用栈但 RPM 安装的 observer 是剥离了调试符号的直接bt只有地址没有源码行。怎么做先用observer -V拿 REVISION 的前半部分去对应的 RPM 仓库找 debuginfo 包解压后用 gdb 的symbol-file加载之后bt就能看到文件路径和行号。# 1. 查版本动态库路径没配好时先补 LD_LIBRARY_PATH LD_LIBRARY_PATH../lib:$LD_LIBRARY_PATH ./observer -V # 2. 从 RPM 中解出 observer.debug rpm2cpio oceanbase-ce-debuginfo-4.1.0.1-102000042023061314.el7.x86_64.rpm | cpio -div # 3. gdb attach 进程或直接打开 coredump 文件加载符号后看栈 gdb ./observer $(pidof observer) (gdb) symbol-file usr/lib/debug/home/admin/oceanbase/bin/observer.debug (gdb) bt日志里打印的lbt()调用栈是一串地址用addr2line -pCfe ./bin/observer 0x...也能翻成函数和源码行这条路径在 调试文档里有完整示例。Debug Sync在生产环境冻结指定线程能做什么gdb attach 会挂起整个进程而 OceanBase 靠心跳维持活性硬挂可能把集群搞出二次故障。debug sync 让特定线程停在代码指定点你随便看现场看完发信号它再继续。怎么做先把debug_sync_timeout设为非 0 打开开关再设置挂起点调完唤醒并清理。-- 打开 debug sync 开关非 0 即开启 alter system set debug_sync_timeout100000s; -- 让线程在指定点挂起等待信号 set ob_global_debug_sync BEFORE_UNIT_MANAGER_LOAD wait_for signal_name execute 10000; -- 现场看完后唤醒 set ob_global_debug_sync now signal signal_name; -- 收尾关闭开关别留在生产里 alter system set debug_sync_timeout0;⚠️ debug sync 在 release 模式下同样生效也就是说生产环境默认就开着这个能力——用完后一定要执行最后两条清理否则别人连进来会踩到你留下的挂起点。踩坑实录坑 1./observer -V报error while loading shared libraries: libmariadb.so.3→ 根因observer 依赖的动态库在旁边的lib/目录里当前进程的库搜索路径没包含它。 → 修复LD_LIBRARY_PATH../lib:$LD_LIBRARY_PATH ./observer -V之后所有手动执行 observer 的操作都带上这个前缀。坑 2gdb 里bt打出来的全是匿名地址没有文件名和参数→ 根因RPM 装的 observer 剥离了调试符号符号在独立的 debuginfo 包里不加载等于盲打。 → 修复按上一节流程解出observer.debug在 gdb 里执行symbol-file /全路径/observer.debug再bt。坑 3日志级别已经 DEBUG想要的日志还是搜不到→ 根因不是没打是被限流丢了。同一个错误超过diag_syslog_per_error_limit条后就不再输出日志写带宽也会撞syslog_io_bandwidth_limit。 → 修复alter system set diag_syslog_per_error_limit1000;和alter system set syslog_io_bandwidth_limit1G;⚠️ 所以搜不到日志别先怀疑自己拼错了 grep。坑 4gdb attach 之后集群心跳超时告警反而更多了→ 根因gdb 挂起的是整个进程多租户 observer 里几百个线程全停心跳、选举保活都断了。官方文档明确建议单线程场景才用 gdb否则优先日志或 debug sync。 → 修复改用 debug sync 只挂目标线程alter system set debug_sync_timeout100000s;配合上一节的挂起/唤醒命令操作。延伸方向本地开发环境IDE 连接远程机器、C 插件配置见 IDE 配置。单元测试用 googletest 写test_xxx.cpp并接入 CMake流程见 单元测试指南CI 跑法长这样SQL 审计分析用仓库自带的 审计脚本 对审计日志做定期归档和统计分析。离线运维备份恢复、日志流工具等底层操作见 ob_admin 工具集。速查表参数 / 命令设置方式建议值作用ob_log_levelset ob_log_leveldebug;生产 info排查期 debug会话级日志级别syslog_io_bandwidth_limitalter system set ...1G日志写带宽上限diag_syslog_per_error_limitalter system set ...1000同一错误最大输出条数enable_async_syslogalter system set ...False;排查期 False改同步打印日志防丢debug_sync_timeoutalter system set ...默认 0关闭排查期100000sdebug sync 总开关last_trace_id()select last_trace_id();—取上一条 SQL 的 trace id先把上面的命令在测试机里按顺序跑一遍docker 起实例、取一次last_trace_id、看一次show trace。有输出了再来说哪里卡住了。【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考