一、 验证背景与目的
本次验证旨在确认在服务器意外或计划性重启后，OceanBase 企业版集群的核心组件（observer、obproxy、ocp_agent）是否能正确且快速地实现服务自启动，同时梳理其双重自启动机制与底层保障。
- 版本
- OCP-V4.3.2
- OB-V4.2.1.6
- ODP-V4.3.1
二、 自启动脚本配置（rc.local 层面）
为确保机器重启后能拉起服务，系统已在 /etc/rc.d/rc.local 的末尾添加了自启动脚本：
/usr/local/bin/auto_start_ob.sh >> /var/log/ob.autostart.log 2>&1 &
图（1）
操作步骤： 注释掉 rc.local 中的自启动脚本，用于验证在原生脚本缺失的情况下，是否仍有其他机制触发 OB 服务启动。
三、 重启前服务状态基线检查
在执行重启操作前，对当前环境状态进行全面检查：
- 进程状态检查（ps -ef）：确认 ocp_agent、observer、obproxy 等关键进程均已正常运行。
图（2）
- 端口监听检查（netstat -nlp | grep 288*）：observer：负责数据库 SQL 端口 2881 及 RPC 端口 2882；obproxy：负责代理端口 2883 及管理端口 2884；ocp_agent：负责服务监控相关端口 62888、62889。
图（3）
- 平台侧状态确认：通过 OceanBase 云平台（OCP）确认集群整体拓扑结构（Zone、机器数量）、OBProxy 集群状态以及主机/Agent状态均显示“在线”且“正常运行”。
- 集群状态
图（4）
- 主机状态
图（5）
四、 执行重启及故障观察（reboot）
输入 reboot 命令后，SSH 终端立即失去连接，表明服务器已进入重启流程。
图（6）
**服务器重启完成后的初步观察：**等待服务器启动完毕并登录后，在 OCP 平台发现 10.0.0.62 节点处于“不可用”状态，显示为红色异常标志。
图（7）
五、 异常恢复过程分析（RootService 视角）
针对 10.0.0.62 异常现象，通过查询 OceanBase 内部的 dba_ob_rootservice_event_history 系统表，复盘了组件恢复的底层过程：
- 10.0.0.62 节点下线：在机器重启瞬间，RootService 检测到节点掉线，10.0.0.62 进行 RootService 卸任操作，系统自动将其设置为永久下线时间。
- 节点重新上线：待机器操作系统启动完成后，observer 进程被拉起并重新注册。
- 集群恢复：RootService 发生切换或重新平衡，执行 load_servers 及 server online 事件，最终将 10.0.0.62 重新加入集群，完成状态恢复。
图（8）
六、 服务恢复与速度分析
在机器重启后，从服务启动的时间戳及各组件状态来看：
- 服务启动极快：机器启动后，系统在极短的时间内（约 4 秒左右）即完成了 observer、obproxy、ocp_agent 等核心服务的拉起。
图（9）
- 端口与进程恢复正常：observer 进程与 2881/2882 端口恢复正常监听；obproxy 进程与 2883/2884 端口恢复正常监听，且进程树显示由 sudo 或特定守护脚本拉起；ocp_agent 进程恢复正常，并在 journalctl 中留下了 starting ocp_agent… 的启动日志。
图（10）
图（11）
七、 根因再验证（systemd 服务干扰排查）
**遇到的现象与疑问：**在注释掉了 /etc/rc.d/rc.local 的自启动脚本后，理论上不应再触发 observer 的拉起，但上述过程依然发生了自动恢复。因此，需要进行更深层级的排查。
**排查关键点：**检查系统服务配置，发现系统层面上（如 system.conf 或专门的 observer.service 服务文件）额外配置了 OB 服务的自启动指令。以 observer.service 为例，文件内定义了 ExecStart=/home/admin/oceanbase/bin/observer 等启动项。
图（12）
**验证操作与结果：**为进一步确认其他服务是否也具备类似机制，对 observer.service 进行注释处理后再次执行 reboot，并观察启动结果：
- 重启后，ocp_agent、obproxy 服务通过其自身的自启动机制依然正常启动了进程。
- observer 进程与对应端口也再次被成功拉起。
图（12）
- 平台中 10.0.0.62 节点的 zone1 状态恢复正常，数据库可以通过指定账号正常连接。
图（13）
八、 最终结论与机制解析
通过上述排查流程与最终现象，结合 OceanBase 企业版实际架构，确认 OB 集群在机器重启后具备双重（且防冲突）的自启动保护机制。
1. 自启动实现方式一：OCP Agent Systemd 自愈机制（优先生效）
在 OceanBase OCP v4.2.0 及后续版本中，平台在主机上安装 ocp_agent 时，会将 ocp_agent.service 安装到 /usr/lib/systemd/system/ocp_agent.service。随后系统通过 systemctl enable ocp_agent 命令，在 /etc/systemd/system/multi-user.target.wants/ 下建立软链接：
/etc/systemd/system/multi-user.target.wants/ocp_agent.service -> /usr/lib/systemd/system/ocp_agent.service
核心逻辑：每次服务器重启时，ocp_agent.service 受 systemd 驱动率先拉起，随后由 ocp_agent 进程负责“自动拉起” observer 和 obproxy 服务。这就是为什么注释掉 rc.local 以及 observer.service 后，服务依然能正常自启的根本原因。
2. 自启动实现方式二：auto_start_ob.sh 脚本兜底机制
部分场景下，用户通过 /usr/local/bin/auto_start_ob.sh 脚本配合 rc.local 实现自启动，其启动序列为：wait_until_startup_finished → autostart_obproxy → autostart_ob → autostart_ocp_agent → autostart_obagent。
3. 冲突规避逻辑（防止双重拉起）
为了防止方式一和方式二同时生效引发启动冲突，脚本内部自带了一套极为关键的冲突规避逻辑：
- 预检查：auto_start_ob.sh 在准备启动前，会先检测主机上是否存在 ocp_agent.service 的 Systemd 服务。
- 条件触发：若主机上存在 ocp_agent.service（即确认方式一已生效），脚本会直接跳过整个自启动流程，不执行拉起动作。即使主机上的 agent 服务未被 Systemd 管理，只要 agent 版本 ≥ 4.2.0，auto_start_ob.sh 依然会跳过整个自启动步骤。
总结
OceanBase 企业版采用了**“OCP Agent 自愈优先，脚本兜底且具备冲突规避”**的精密设计。在日常运维中，我们无需额外在 rc.local 或 systemd 中重复设置自启动。只需定期检查 ocp_agent.service 状态，确认其处于 enable 状态，即可保证数据库组件在服务器意外断电或重启后的高可用自动恢复