ocp重启一直卡在ocp-server-ce program health check

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境 ：生产环境
【 OB or 其他组件 】OCP
【 使用版本 】4.4.2.1
【问题描述】OCP启动一直卡在ocp-server-ce program health check
【复现路径】obd cluster start myocp
【附件及日志】
命令：obd cluster start myocp
输出：
Get local repositories ok
Load cluster param plugin ok
Open ssh connection ok
Check before start ocp-server-ce ok
cluster scenario: None
Start observer ok
observer program health check ok
Connect to observer 172.29.31.8:2881 ok
obshell start ok
obshell program health check ok
start obproxy ok
obproxy program health check ok
Connect to obproxy ok
extract compressed doc ok
Start ocp-server-ce ok
ocp-server-ce program health check

@论坛小助手

#3

@论坛小助手 哪里可以看到ocp的启动日志，~/ocp-server/log下的ocp.log、bootstrap.log、startup.log都没有最新日志，~/ocp/log/ocp-server.log好像也没有

#4

根据您的问题描述，您在使用 obd cluster start myocp 启动 OCP 时遇到了卡在 ocp-server-ce program health check 的情况，并且您尝试查找的日志文件未显示最新的日志信息。以下是一些可能帮助您解决此问题的步骤：

1. 检查OCP容器内部日志

由于您提到的标准日志路径没有新的日志输出，可以考虑直接检查 OCP 容器内部的日志以获取更多信息。

  • 如果是通过 Docker 部署的 OCP，请执行以下命令进入 OCP 容器：
    docker exec -it <ocp-container-id-or-name> bash
    然后在容器内查看相关日志，如 /home/admin/logs/ocp/ocp.log 和 /home/admin/logs/ocp/bootstrap.log。

2. 查看OBD部署过程中的详细日志

  • 根据文档片段6的信息，如果您的 OCP 是通过 OBD 部署的，您可以查看 OBD 的日志来确认更详细的内容。日志文件通常位于 ~/.obd/log/obd 目录下。
  • 对于 OCP 自身的日志，如果您是用 OBD 部署，则应该在 OCP 部署路径下的 log 子目录中查看，比如 less ${ocp_home_path}/log/ocp-server.log。

3. 增加OBD日志级别

有时默认的日志级别不够高，导致某些重要信息未被记录下来。您可以尝试增加 OBD 的日志级别，以获得更加详细的日志信息。

  • 修改 OBD 的配置或在启动命令中指定更高的日志级别（如果支持）可能会有助于发现具体问题所在。

4. 联系技术支持

  • 如果上述方法仍无法解决问题，建议联系 OceanBase 技术支持团队，并提供尽可能多的相关信息，包括但不限于：OBD 日志、OCP 容器内部日志以及任何可用的错误消息或异常堆栈跟踪等。参考如何向技术支持提问。

5. 其他检查点

  • 确保所有必要的依赖服务均已正确运行。
  • 确认是否有足够的资源分配给 OCP 服务（例如内存、CPU）。
  • 检查网络连接是否正常，尤其是与数据库实例之间的通信链路。

希望这些建议能帮助到您解决问题！如果需要进一步的帮助，请随时告知。

检索到的文档如下:

  1. 使用容器升级 OCP
  2. 使用图形化界面升级 OCP
  3. 使用图形化界面部署 OCP
  4. 使用容器部署 OCP
  5. 部署常见问题
  6. 查看主机详情
  7. 重启 OCP
  8. base_secondary_backup_fail 数据二次备份任务失败
  9. 遇到问题如何向技术支持同学提问
#5

~/.obd/log/obd目录下的日志是：

[2026-08-31 16:22:49.330] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- root@172.29.31.14 execute: bash -c 'cat /proc/net/{tcp*,udp*}' | awk -F' ' '{print $2,$10}' | grep '00000000:1F90' | awk -F' ' '{print $2}' | uniq 
[2026-08-31 16:22:49.391] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- exited code 0
[2026-08-31 16:22:49.391] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- failed to start 172.29.31.14 ocp-server-ce, remaining retries: 39
[2026-08-31 16:23:04.391] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- 172.29.31.14 program health check
[2026-08-31 16:23:04.392] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- root@172.29.31.14 execute: ls /proc/948538 
[2026-08-31 16:23:04.402] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- exited code 0
[2026-08-31 16:23:04.402] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- root@172.29.31.14 execute: bash -c 'cat /proc/net/{tcp*,udp*}' | awk -F' ' '{print $2,$10}' | grep '00000000:1F90' | awk -F' ' '{print $2}' | uniq 
[2026-08-31 16:23:04.464] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- exited code 0
[2026-08-31 16:23:04.465] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- failed to start 172.29.31.14 ocp-server-ce, remaining retries: 38
[2026-08-31 16:23:19.465] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- 172.29.31.14 program health check
[2026-08-31 16:23:19.466] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- root@172.29.31.14 execute: ls /proc/948538 
[2026-08-31 16:23:19.476] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- exited code 0
[2026-08-31 16:23:19.476] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- root@172.29.31.14 execute: bash -c 'cat /proc/net/{tcp*,udp*}' | awk -F' ' '{print $2,$10}' | grep '00000000:1F90' | awk -F' ' '{print $2}' | uniq 
[2026-08-31 16:23:19.539] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- exited code 0
[2026-08-31 16:23:19.539] [57222638-a512-11f1-91dd-fa4b4ccc1200] [DEBUG] -- failed to start 172.29.31.14 ocp-server-ce, remaining retries: 37
#6

obd日志中，一直retries到1以后失败

[ERROR] [ERROR] failed to start 172.29.31.14 ocp-server-ce
[2026-08-31 16:32:37.320] [DEBUG] - sub health_check ref count to 0
[2026-08-31 16:32:37.320] [DEBUG] - export health_check
[2026-08-31 16:32:37.320] [DEBUG] - plugin ocp-server-ce-py_script_health_check-4.2.1 result: False
[2026-08-31 16:32:37.321] [DEBUG] - share lock /root/.obd/lock/mirror_and_repo release, count 3
[2026-08-31 16:32:37.321] [DEBUG] - share lock /root/.obd/lock/mirror_and_repo release, count 2
[2026-08-31 16:32:37.322] [DEBUG] - share lock /root/.obd/lock/mirror_and_repo release, count 1
[2026-08-31 16:32:37.322] [DEBUG] - share lock /root/.obd/lock/mirror_and_repo release, count 0
[2026-08-31 16:32:37.322] [DEBUG] - unlock /root/.obd/lock/mirror_and_repo
[2026-08-31 16:32:37.322] [DEBUG] - exclusive lock /root/.obd/lock/deploy_myocp release, count 0
[2026-08-31 16:32:37.322] [DEBUG] - unlock /root/.obd/lock/deploy_myocp
[2026-08-31 16:32:37.322] [DEBUG] - share lock /root/.obd/lock/global release, count 0
[2026-08-31 16:32:37.322] [DEBUG] - unlock /root/.obd/lock/global
[2026-08-31 16:32:37.322] [INFO] Trace ID: 57222638-a512-11f1-91dd-fa4b4ccc1200
#7

发一下obd.log文件 看一下

#8

问题已解决，原因出在obproxy未正确连接，让AI去部署obproxy，AI降级在目标服务器上装了个端口转发