OceanBase 集群单节点安全停机运维

by

在分布式数据库的日常运维中，对单个节点进行停机维护（如硬件升级、系统打补丁、配置调整等）是再常见不过的场景。对于 OceanBase 而言，其多副本与 Paxos 协议的高可用特性，让我们在维护单节点时完全可以做到业务无损。

但是，“怎么停”和“停多久”大有讲究。本文将为你梳理一套标准、安全的单节点停机运维方案，并深入解析临时停机与永久停机的核心区别。最近有家金融客户需要做该操作，简单整理一下方法

核心概念：临时停机 vs 永久停机

在动手敲命令之前，必须先明确一个核心参数：server_permanent_offline_time。该参数默认值为 1小时，它是判断节点是“短暂休息”还是“永久退休”的分水岭。

  • 临时停机（< 1小时）：适用于常规重启或短时排查。只要在规定时间内恢复，集群不会触发数据副本的自动补全，恢复速度最快。
  • 永久停机（> 1小时）：适用于长时间硬件维修或机器替换。如果超过时限未恢复，集群会判定该节点永久下线，并触发副本自动迁移，这会给集群带来额外的 IO 和 CPU 负载。

💡 运维建议：如果你预计维修时间会超过 1 小时，但依然想保留该节点，建议在停机前提前调大 server_permanent_offline_time 的值（例如调整为 3 小时或更长）。对于Oracle DBA 把这个参数理解成ASM fast mirror resync中的DISK_REPAIR_TIME。

server_permanent_offline_time 配置

OceanBase 数据库通过 server_permanent_offline_time 配置项来控制 OBServer 的永久下线时间，默认为 3600s，取值范围为 [20s, +∞)。对于一台 OBServer，RootService 会通过检查心跳的方式按照 100 ms 的间隔定期检查此 Server 的状态，并记录 last_hb_time 为 OBServer 最近保持心跳的时间。当 last_hb_time 超过 server_permanent_offline_time 配置项指定的值后，该 OBServer 会被标记为永久下线，此后会触发 unit 复制和副本迁移动作。

server_permanent_offline_time 配置项的使用场景如下：

  • OBServer 升级流程：进行版本升级时，OceanBase 数据库会自动将该参数设置为 72h（72 小时）。
  • OBServer 硬件更换：建议将该参数设置为 4h（4 小时）。
  • OBServer 清空上线：建议将该参数设置为 10m（10 分钟），使集群快速上线。

临时停机标准停机步骤

1.停止 obproxy 进程

在进行节点停机维护前，为了避免业务连接中断或路由异常，建议先优雅地停止该节点上的 obproxy 进程。

  1. 查找进程 ID： 使用 ps 命令查找 obproxy 相关的进程。
ps -ef | grep obproxy | grep -v grep
  1. 正常终止进程： 获取到进程 ID (pid) 后，使用标准的 kill 命令终止进程（强烈不建议直接使用 kill -9 强制杀进程，除非进程卡死无响应）。

以下流程适用于绝大多数计划内的单节点停机维护场景：

2.停止节点服务（逻辑下线） 首先，需要将目标节点从集群中逻辑隔离。执行此命令后，ODP（OceanBase 代理）将不再把新流量路由到该节点，同时集群会自动将该节点上的 Leader 副本切走。

-- 在 sys 租户中执行，svr_port 默认为 2882
ALTER SYSTEM STOP SERVER '172.xx.xx.xx:2882';

验证方法：查询 oceanbase.DBA_OB_SERVERS 视图，该节点的 STOP_TIME 字段会从 NULL 变为具体的时间点。

3. 执行转储操作（Minor Freeze） 为了缩短后续重启节点后回放 Redo Log 的时间，加速节点恢复，建议对即将停机的节点执行转储。

ALTER SYSTEM MINOR FREEZE SERVER = ('172.xx.xx.xx:2882');

注意：必须等待转储任务完全结束后，再进行下一步。

4. 停止 observer 进程（物理停机） 使用 admin 用户登录目标服务器，进入安装目录（默认为 /home/admin/oceanbase），查找并强制停止进程。

# 1. 获取进程 ID (pid)
ps -ef | grep observer | grep -v grep
​
# 2. 强制停止进程
kill -9 [pid]
​
# 3. 确认进程已消失
ps aux | grep observer

以上前三部都可以在OCP上操作，“停止服务”–>”停止进程”（勾选”停止进程 前执行转储操作“）。

5.执行运维操作 此时节点已完全脱离集群，你可以安全地对机器进行停机、硬件维修、系统升级等操作。

注意：不要超过server_parameter_offline_time时间

6.启动 observer 进程 运维完成后，在服务器上重新启动 observer 进程。

cd /home/admin/oceanbase && ./bin/observer

验证方法：查询 oceanbase.DBA_OB_SERVERS 视图，START_SERVICE_TIME 字段不为 NULL 即代表进程启动成功, 实际是具体的启动时间。

7.恢复节点服务（重新上线） 最后，将节点重新加入集群对外提供服务。

ALTER SYSTEM START SERVER '172.xx.xx.xx:2882';

同样也可以从OB OCP上操作，在observer列表，点击”启动“即可。

8. 启动obproxy

1. 常规手动启动 进入 obproxy 的安装目录（通常在 /home/admin/obproxy-x.x.x 下），执行启动命令：

cd /home/admin/obproxy-x.x.x && bin/obproxy -r "172.xx.xx.xx:2881" -p 2883 -c [集群名] -o "enable_strict_kernel_release=false,enable_cluster_checkout=false,enable_metadb_used=false"
  • -r：指定 OceanBase 集群的 RootService 地址（IP:RPC_PORT，默认 RPC 端口为 2882，SQL 端口为 2881）。
  • -p：指定 obproxy 的监听端口（默认为 2883）。
  • -c：指定要连接的 OceanBase 集群名称。

2. 使用守护进程启动（推荐生产环境） 在生产环境中，为了保证 obproxy 的高可用，通常会配合守护进程 obproxyd.sh 一起使用。守护进程会周期性检查 obproxy 的健康状态，一旦发现宕机会立即自动拉起。 启动命令示例：

./bin/obproxyd.sh -c start -e [环境名] -n [业务名]

注意：如果你手动 kill 掉了 obproxy 进程，但发现它立刻又被自动重启了，大概率就是因为后台有 obproxyd.sh 守护进程在运行。此时需要先停掉守护进程，或者通过守护进程脚本来进行停止操作。

运维小贴士
  • 端口检查：obproxy 启动后，默认会监听两个端口（如 2883 和 2884）。你可以通过 netstat -ntlp | grep obproxy 来确认端口监听是否正常。
  • 无状态特性：因为 obproxy 不存储业务数据，所以在节点停机维护期间，只要负载均衡层（如 LVS、F5 或客户端配置）将该节点的流量切走，停止 obproxy 对整体业务是透明且无损的。

以从OB OCP上操作，在obproxy列表，点击”启动“即可。

恢复之前的server_permanent_offline_time参数

永久停机标准停机步骤

在observer如硬件、操作系统等损坏时，需要从集群中把overserver节点进行替换。

过 OCP 来替换 OBServer 节点需要满足以下条件：

  • 在 1-1-1 副本环境中，有空闲机器替换。
  • 在大于 1-1-1 副本环境中，负载可以全移到其中一台 OBServer 上的场景，可以允许下线一台服务器。

在不满足以上条件的场景中，您可以通过命令行来替换 OBServer 节点。

  • 对于文件目录被误删的场景，您可以通过清理文件目录的方式，将 OBServer 重新加入集群。
  • 对于操作系统或硬件损坏的场景，您需要准备一台服务器作为 OBServer 加入集群。

官方有具体的方法https://www.oceanbase.com/knowledge-base/oceanbase-database-20000000081

Leave a Comment