OceanBase 代理接入口
OceanBase 的连接代理端口：应用统一连 OBProxy 的 2883，由它把 SQL 路由到后端合适的 OBServer，并承担负载均衡与故障切换，这是生产环境的标准接入姿势。OBProxy 自身也是多实例部署，前面通常还有 VIP 或负载均衡。
基本信息
| 服务 | OBProxy |
|---|---|
| 协议 | TCP（MySQL 方言） |
| 默认端口 | 2883 |
| 后端 | OBServer 的 2881 |
| 暴露面 | 仅应用网段 |
典型使用场景
- 应用连接生产集群的标准入口
- 多台 OBProxy 加 VIP 消除中间件单点
- 按租户与集群做路由（连接串中带集群标识）
- 灰度发布：按 OBProxy 实例切换流量
- 排查偶发连接失败：看路由与超时日志
接入与日志核对
接入与日志核对
mysql -hobproxy-vip -P2883 -uapp@tenant -p -e 'SELECT 1'
ss -lntp | grep 2883
# 连接串格式: -u<user>@<tenant>#<cluster>
# OBProxy 日志通常位于 /home/admin/obproxy/log/排障与核对
| 检查项 | 做法 | 异常表现 |
|---|---|---|
| 端口监听 | ss -lntp | grep 2883 | 端口不在：OBProxy 未起或配置被改 |
| 路由结果 | 连接后查询后端节点信息 | 集中打到同一台：路由或负载配置异常 |
| 后端连通 | OBProxy 日志中的连接错误 | 报后端不可达：先查 observer 与网络 |
| 长连接 | 应用侧连接与超时日志 | 偶发闪断：代理重启或超时配置偏短 |
OBProxy 自身也要高可用：单台代理挂掉时后端数据库健康也全站不可用。前面配 VIP 或多实例负载均衡是常规做法，升级 OBProxy 同样要按变更窗口滚动执行。
应用侧只需要知道一件事
应用只应知道 OBProxy 的地址与端口，不需要知道后端有多少台 OBServer。一旦应用里出现 2881 直连配置，扩容与故障切换的好处就全部消失；连接串里还要带对租户与集群标识，写错会连到错误租户上。
OBProxy 日志记录了路由决策与超时信息，是排查偶发连接失败的第一手材料；把日志接入集中平台，比事后逐台登录翻文件高效得多。
OBProxy 单节点部署：代理一挂全站数据库不可用，脆弱程度甚至高于后端数据库本身。
升级 OBProxy 要按实例滚动执行，每台升级后确认端口监听与路由正常，避免一次性停掉全部代理造成业务中断。