OceanBase 分布式集群查询本地执行计划时出现 obproxy 路由分发异常问题排查

OceanBase 技术问题
,
#1

部分带分区键过滤的查询，本该路由至对应分区所在 OB 节点本地执行，实际被 OBProxy 随机分发到其他节点，触发跨节点数据拉取，SQL 耗时从几十 ms 飙升至 3s 以上

2 个赞
#3

6666

#4

@论坛小助手

#5

OceanBase 分布式集群查询本地执行计划时出现 obproxy 路由分发异常问题排查

根据您的描述，部分带分区键过滤的查询本应路由至对应分区所在 OB 节点本地执行，但实际上被 OBProxy 随机分发到其他节点，导致跨节点数据拉取和 SQL 执行时间显著增加。下面是可能的原因及排查步骤：

  1. 检查是否直连了 Follower 节点
    如果应用直接连接到了租户的 Follower 节点而非通过 OBProxy 连接 Leader 节点，那么可能会出现这种情况。您可以通过检查执行计划的统计信息来确认是否直连了 Follower。

  2. OBProxy 无法正确解析 SQL
    如果 OBProxy 在解析 SQL 语句时未能准确计算出需要访问的分区 ID，它可能会随机选择一个节点进行转发。这通常发生在 SQL 语句较为复杂或分区键不明确的情况下。建议检查 OBProxy 的日志文件，寻找类似于 fail to caculate partition id, just use tenant server 的错误信息。如果发现此类错误，则需要调整 SQL 写法，确保包含了足够的分区键信息以便 OBProxy 正确解析。

  3. 分区刚刚切换领导者（Leader）
    如果某些分区最近发生了 Leader 切换，而 OBServer 或 OBProxy 上缓存的位置信息尚未更新，也可能导致查询被发送到错误的节点上。对于这种情况，一般不需要特别处理，等待一段时间让位置缓存刷新即可解决。但若频繁发生，可能需要进一步调查为什么分区频繁切换 Leaders。

  4. 检查 ODP (OceanBase Data Proxy) 配置

    • 确保 ODP 已经开启了对表分布信息的支持，并且能够根据实际的数据分布情况做出最优路由决策。
    • 检查是否有更高级别的路由策略可以启用，例如基于地理位置的选择优先级：同机房 > 同城不同机房 > 不同城市，以减少网络延迟。

  5. 查看 OBProxy 和 OBServer 日志

    • 深入查看 OBProxy 和涉及的 OBServer 的日志文件，寻找更多关于路由失败的具体原因。
    • 特别关注与分区分配、Session 创建、事务启动等相关的信息。

  6. 使用 EXPLAIN 命令分析执行计划

    • 使用 EXPLAIN 命令查看这些查询的实际执行计划。理想情况下，你应该看到所有操作都在同一个 OBServer 上完成，而不是涉及到多个服务器之间的交互。
    • 比较预期的本地执行计划与实际得到的分布式执行计划之间的差异，有助于定位问题根源。

  7. 考虑升级 OBProxy 或 OceanBase 版本

    • 如果当前使用的 OBProxy 或者 OceanBase 版本较老，可能存在已知的问题或者性能瓶颈。查阅官方文档了解是否有相关的修复补丁或新版本发布。

请按照上述建议逐一排查问题，希望这对解决问题有所帮助。如果仍然无法解决，请联系 OceanBase 支持团队获取进一步的帮助。

更多信息请查看:

  1. 分布式执行和并行查询
  2. 数据路由影响因素
  3. 分布式事务
  4. 函数分区键路由概述
  5. 性能分析
  6. ODP SQL 路由原理
  7. 数据库应急概述
  8. 产品 FAQ
#6

如果有案例的话 可以发出来看看 具体的执行计划 还有第一个表的leader节点 是哪一个 可以发出来看看
obdiag gather plan_monitor --trace_id YB420BA2D99B-0005EBBFC45D5A00-0-0
–env host=xx.xx.xx.xx --env port=2881 --env user=root@test --env password=*** --env database=test
https://www.oceanbase.com/docs/common-obdiag-cn-1000000006175714
使用obdiag收集一下信息

#7

很好