ob binlog 服务突然异常

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

【 使用环境 】生产环境 or 测试环境
【 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

【 使用环境 】 生产环境
【 其他组件 】binlog server 组件
【 使用版本 】4.2.10-100000032025082811
【问题描述】binlog 服务突然异常，日志提示无法访问 binlog_database [2025-09-16 12:24:49.701861] [error] mysql_connecton_wrapper.cpp(208): Failed to return connection to pool, conn is invalid
[2025-09-16 12:24:49.701910] [warning] mysql_connecton_wrapper.cpp(40): Failed to obtain connection, try to reconnect
[2025-09-16 12:24:49.701947] [error] mysql_connecton_wrapper.cpp(208): Failed to return connection to pool, conn is invalid
[2025-09-16 12:24:49.701963] [warning] mysql_connecton_wrapper.cpp(40): Failed to obtain connection, try to reconnect
[2025-09-16 12:24:49.701995] [error] mysql_connecton_wrapper.cpp(208): Failed to return connection to pool, conn is invalid
[2025-09-16 12:24:49.702040] [warning] mysql_connecton_wrapper.cpp(40): Failed to obtain connection, try to reconnect
[2025-09-16 12:24:49.707228] [error] mysql_connecton_wrapper.cpp(179): Failed to connect to mariadb platform: Could not connect to address=(host=xxx)(port=2881)(type=master) : Tenant not in this server,url:jdbc:mariadb://xxxx:2881/binlog_database

#3

针对您提到的生产环境中 OceanBase 4.2.10-100000032025082811 版本的 binlog 服务出现的异常情况，日志中显示的问题为无法访问 binlog_database，错误信息为 ‘Failed to return connection to pool, conn is invalid’ 和 ‘Tenant not in this server’。这可能是由于租户未在当前服务器上或连接池中的连接失效所导致的。

推荐您使用 obdiag 工具进行日志采集，这有助于我们进一步分析问题。同时，您可以尝试以下步骤来解决当前问题：

日志采集

日志采集场景: 日志归档问题
日志采集命令: obdiag gather scene run --scene=observer.log_archive

该命令将帮助我们收集与 binlog 相关的日志信息，以便于后续分析。

提供更多信息

为了更准确地定位和解决问题，请您提供以下信息：

  1. 当前集群的架构图或简要描述，包括租户的分布情况。
  2. 问题发生的时间点，以及在此之前是否有过任何维护操作（如升级、配置变更等）。
  3. 出现问题的具体租户名称及其相关信息。
  4. 该租户是否在多个 OBServer 上存在副本，如果是，请说明副本的分布情况。
  5. 如果可能，提供出现问题前后一段时间内的系统日志文件。

通过以上信息，我们可以更好地理解您的环境和问题，从而提供更加有效的解决方案。感谢您的配合！

附上敏捷诊断工具 obdiag 使用帮助链接

#4

SHOW VARIABLES like ‘version_comment’; ob的版本号查一下

binlog服务直接断了么？logproxy.log obproxy.log 日志提供一下

#5

image
image1516×288 63.8 KB

看着是binlog链接库的有问题呀 binlog_database这个库是ob的的集群么？

#6

查到原因了，用 ocp 创建的 binlog 集群 metadb 不是 obproxy 路由的，指定了一个 observer 的2881 ，这个server 的 unit 发生迁移后，就会出现 tenant not in this server ，把这个集群的自动迁移功能关了，然后重启了这个 binlog 集群就恢复了