ODP错误日志中出现大量的-4124错误

OceanBase 技术问题
,
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】OceanBase 4.2.2.1 ODP 4.2.3.0
【 使用版本 】社区版
【问题描述】业务反馈程序连接OB有时候会自动断开，集群和租户运行正常，ODP错误日志中出现大量的 -4124 UnKnow error。ODP内存为30G，目前连接数不是非常大，感觉不像ODP资源的问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

#3

根据文档库中的信息，对于您提到的 ODP 错误日志中出现大量的 -4124 UnKnow error 问题，目前直接相关的错误码解释和解决方案在提供的文档片段中没有明确提及。但是，可以提供一些通用的排查思路和建议：

  1. 检查连接稳定性：
    根据文档片段 1 和文档片段 10 的内容，ODP 会感知 OBServer 的异常状态，并避免将应用流量路由到异常节点上。如果某个节点不稳定，可能会导致客户端感受到不稳定，进而引发连接断开的问题。您可以检查是否有节点处于 INACTIVE 状态或存在响应慢的情况。可以通过查询 oceanbase.DBA_OB_SERVERS 视图来获取服务器的状态信息。

  2. 资源检查：
    尽管您提到 ODP 内存为 30G 并且当前连接数不大，但仍然建议检查 ODP 和 OceanBase 集群的整体资源使用情况，确保没有其他潜在的资源瓶颈。特别是租户内存资源是否充足（参考文档片段 9），以及是否存在内部模块内存不足/泄漏的问题（参考文档片段 3）。

  3. 日志分析：
    使用 OceanBase 敏捷诊断工具 obdiag 收集诊断信息，详细分析 ODP 和 OceanBase 的日志文件，寻找更多关于 -4124 错误的具体上下文信息。这有助于更准确地定位问题根源。

  4. 版本兼容性：
    您提到使用的是 OceanBase 4.2.2.1 和 ODP 4.2.3.0 版本，请确认这两个组件之间的版本兼容性，确保没有已知的兼容性问题导致此类错误。

  5. 联系支持：
    如果经过上述步骤仍无法解决问题，建议联系 OceanBase 的官方技术支持团队，提供详细的日志和诊断信息，以便获得更专业的帮助和支持。

综上所述，虽然无法从检索到的文档中找到解决此问题的直接信息，但通过以上方法可以逐步排查并尝试解决问题。希望这些建议对您有所帮助。

检索到的文档如下:

  1. 数据库应急概述
  2. 代理层高可用
  3. OBKV-HBase 高可用
  4. 4500 ~ 4999
  5. ODP 性能分析
  6. OceanBase 数据库整体架构
  7. OceanBase 数据库代理（ODP）
  8. 4000 ~ 4499
  9. 数据库层高可用
#4

ODP相关配置

image
image1627×699 171 KB

image
image1644×618 134 KB

#5

根据您提供的 ODP 配置信息，以下是对配置项的详细解释以及针对 -4124 UnKnow error 错误的一些进一步分析和建议：

ODP 配置项解释

  1. internal_cmd_mem_limited

    • 内部命令响应内存限制，默认范围为 [0, 64MB]。设置为 0 表示不限制。

  2. proxy_mem_limited

    • 代理层内存限制，默认范围为 [100MB, 100G]。当前配置为 30G，这与您提到的 ODP 内存一致。

  3. client_max_memory_size

    • 单个客户端会话的最大动态分配内存大小，默认值为 24MB。这个值通常不需要调整，除非有特殊需求。

  4. sql_table_cache_mem_limited

    • SQL 表缓存的最大内存大小，默认为 128MB。此参数影响查询性能，但一般情况下无需特别调整。

  5. mem_leak_check_mod_name 和 mem_leak_check_class_name

    • 这两个参数用于记录内存分配回溯信息，帮助排查内存泄漏问题。当前配置为 ALL; (BHM) 和 512MB，表示对所有模块进行检查，并且设置了最大内存限制。

  6. sqlaudit_mem_limited

    • SQL 审计内存限制，默认范围为 [0, 1GB]。当前配置为 512MB。

  7. routing_cache_mem_limited

    • 所有路由缓存（如表缓存、位置缓存等）的最大内存大小，默认为 512MB。

  8. max_connections

    • 单个 OBProxy 实例允许的最大客户端连接数，默认为 65535。当前配置也是 65535，表明没有额外限制。

  9. connection_diagnosis_option

    • 连接诊断控制选项，位 1 表示记录连接诊断信息。当前配置为 True，意味着启用了连接诊断功能。

  10. enable_connection_diagnosis

    • 是否启用连接诊断，默认为 False。当前配置为 True，即启用了连接诊断。

  11. enable_client_connection_lru_disconnect

    • 当客户端连接达到阈值时，是否允许新连接替换旧连接，默认为 False。当前配置为 False，即不允许新连接替换旧连接。

针对 -4124 UnKnow error 的进一步分析

尽管从配置上看，ODP 的资源设置看起来是合理的，但仍然存在一些潜在的问题点需要进一步排查：

  1. 连接稳定性：

    • 检查是否有频繁的短连接或长连接超时情况。可以通过日志中的连接诊断信息来确认是否存在异常断开的情况。如果启用了连接诊断功能，可以查看具体的诊断日志以获取更多信息。

  2. 内部模块内存不足/泄漏：

    • 尽管 ODP 内存配置为 30G，但如果某些内部模块（如 SQL 审计、路由缓存等）占用过多内存，可能会导致其他部分资源紧张。建议监控各个模块的实际内存使用情况，确保没有内存泄漏或过度消耗的问题。

  3. 网络延迟或丢包：

    • 确认网络环境是否稳定，特别是 OBProxy 和 OceanBase 集群之间的通信链路。高延迟或丢包可能导致连接不稳定，进而引发错误。

  4. 版本兼容性：

    • 再次确认 OceanBase 4.2.2.1 和 ODP 4.2.3.0 之间的版本兼容性。虽然理论上应该兼容，但仍需排除是否存在已知的兼容性问题。

  5. 日志分析：

    • 使用 OceanBase 敏捷诊断工具 obdiag 收集详细的日志信息，重点分析 -4124 UnKnow error 发生前后的时间段内的日志，寻找更多线索。

建议操作

  • 启用更详细的日志记录：可以在 ODP 中启用更详细的日志级别，以便更好地捕捉错误发生时的具体上下文信息。

  • 监控资源使用情况：持续监控 ODP 和 OceanBase 集群的资源使用情况，包括 CPU、内存、磁盘 I/O 和网络带宽等，确保没有资源瓶颈。

  • 联系官方支持：如果经过上述步骤仍无法解决问题，建议联系 OceanBase 的官方技术支持团队，提供详细的日志和诊断信息，以便获得更专业的帮助和支持。

希望这些建议能帮助您更好地排查和解决 -4124 UnKnow error 问题。如果有任何进一步的问题或需要更多帮助，请随时告知。

具体信息可参考以下文档:

  1. 全量旁路导入
  2. Case 编写注意事项

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#6

提供一下obproxy.log 、 obproxy_diagnosis.log 、 obproxy_digest.log

#7

已经排查完了，有一个observer挂掉了

#8

好的 ocp会有告警的 应该能监测到的

1 个赞
#9

感谢分享！