安全和协议 - 数据库代理 V4.3.0

安全和协议

更新时间：2026-04-14 17:41:06

安全能力

安全的目的主要是满足合规要求和防范攻击。从整个体系和访问链路来看安全，应该包括平台安全、ODP 安全和 OceanBase 数据库安全。

对于 ODP 安全来说，主要是连接、访问控制、中间件安全能力和自身安全。

密码保护

ODP 有两个特殊的账号：root@proxysys 和 proxyro@sys，这里 root@proxysys 是 ODP 的管理员账号，proxyro@sys 是 ODP 访问 OceanBase 数据库的账号。这两个账户都支持修改密码，其中 root@proxysys 的密码对应配置项 obproxy_sys_password，proxyro@sys 的密码对应配置项 observer_sys_password，为了实现 proxyro 的平滑改密（不重启），3.x 版本增加了 observer_sys_password1。

注意

如果通过登录 root@proxysys 的方式（如 mysql -h127.1 -P2883 -uroot@proxysys -pxxx)，使用命令 alter proxyconfig set obproxy_sys_password = 'xxx'; 设置密码，语句中的 xxx 就是密码的内容。
如果通过 -o 方式设置，内容为密码的 sha1 值，不推荐使用该方式。

SSL 能力

SSL 使用需要有一定要求：

证书体系：不同客户可能有自己的密钥分发体系，需要适配
周边产品：访问链路上，需要驱动、ODP、OBServer 节点都支持，多段 TCP 链路根据选择打开

从全链路看，Client 与 ODP 以及 ODP 与 OBServer 节点之间，和 ODP 相关的链路有两条，ODP 支持两条链路的 SSL 加密能力。可以根据整体架构确定开启哪一段的 SSL 能力。举个例子，在公有云场景的 SSL 使用如下：

SSL

不同 VPC 之间通过 SSL 保证数据加密，VPC 内部通过网络隔离保证安全。SSL 对整体的性能影响在 5% 以内。

密钥设置

开启 ODP 的 SSL 能力，首先需要进行密钥设置。使用 ODP 的 root@proxysys 账号登录后，通过文件设置证书、公钥、私钥。示例如下：

replace into ssl_config(cluster_name, tenant_name, name, value) values("cluster1", "tenant1", "key_info", "xxx");
update proxyconfig.security_config set CONFIG_VAL= '{"sourceType" : "FILE", "CA" : "certs/ca.pem", "publicKey" : "certs/server-cert.pem", "privateKey" : "certs/server-key.pem"}' where APP_NAME = 'obproxy' and VERSION = '1';

其中:

sourceType 字段必须设为 FILE
CA 表示 CA 证书的存放位置
publicKey 表示公钥证书的存放位置
privateKey 表示私钥证书的存放位置

SSL 开关

ODP 有两个 SSL 开关，enable_client_ssl 控制 Client 与 ODP 之间的 SSL 能力，enable_server_ssl 控制 ODP 与 OBServer 节点之间的 SSL 能力。

设置如下：

# 1.x 系列
alter proxyconfig set enable_client_ssl = xxx;
alter proxyconfig set enable_server_ssl = xxx;

# 3.x 系列租户级别
replace into proxy_config(cluster_name, tenant_name, name, value) values("cluster1", "tenant1", "enable_client_ssl", "true");
replace into proxy_config(cluster_name, tenant_name, name, value) values("cluster1", "tenant1", "enable_server_ssl", "false");

查看 SSL 状态

对于 Client 到 ODP 这段连接的 SSL 状态，可以通过 show proxysession 命令的 using_ssl 字段查看。ODP 到 OBServer 节点这段连接的 SSL 状态，通过 OBServer 节点查询获得。实际使用中，可以灵活设置开启哪段 SSL 能力。

对于 ODP 来说，配置的生效级别为：租户 > 集群 > 全局。除此之外，开启 SSL 还需要各个组件协商确定，要使用 SSL 能力，驱动和数据库的 SSL 开关也需要打开。

白名单和连接数

ODP 可以控制客户端的访问白名单，目前该能力做到了租户级别，可以对每个租户单独设置。在 root@proxysys 账户下，ODP 提供了内部表 white_list，里面保存了白名单信息，目前 ODP 支持白名单为 IP 或者 IP 和网络号，白名单功能在公有云上已经广泛使用。

replace into white_list(cluster_name, tenant_name, name, value) values('cluster1', 'tenant1', 'ip_list', '127.0.0.1,168.xxx.0.0/16');

协议

ODP 支持三种协议：

MySQL 协议：和原生 MySQL 协议一致
压缩协议：对 MySQL 协议内容进行压缩，保证数据传输正确性
OceanBase 2.0 协议：自研协议，支持更多特性开发

注意

在 ODP 4.x 版本和 OceanBase 数据库 4.x 版本中不允许关闭 OceanBase 2.0 协议，否则会有功能缺失。

有以下三个配置项控制协议使用：

enable_ob_protocol_v2：判断是否使用 OceanBase 2.0 协议，详细介绍可参见 enable_ob_protocol_v2。
enable_compression_protocol：判断是否使用压缩协议，详细介绍可参见 enable_compression_protocol。
compression_algorithm：用于控制压缩协议和 OceanBase 2.0 协议的压缩级别。详细介绍可参见 compression_algorithm。

压缩协议和 OceanBase 2.0 协议都会对数据进行校验，保证数据正确性。其中，enable_ob_protocol_v2 的优先级高于 enable_compression_protocol，两个配置项都为 False 则表示使用普通协议。

功能特性

目前新的特性都是基于 OceanBase 2.0 协议开发，OceanBase 2.0 协议格式如下：

OceanBase 2.0 Protocol Format：

   0       1         2           3          4        Byte
   +-----------------+----------------------+
   |    Magic Num    |       Version        |
   +-----------------+----------------------+
   |            Connection Id               |
   +-----------------------------+----------+
   |         Request Id          |   Seq    |
   +-----------------------------+----------+
   |            PayLoad Length              |
   +----------------------------------------+
   |                Flag                    |
   +-----------------+----------------------+
   |    Reserved     |Header Checksum(CRC16)|
   +-----------------+----------------------+
   |        ... PayLoad  Data ...           |----------+
   +----------------------------------------+          |
   |    Tailer PayLoad Checksum (CRC32)     |          |
   +----------------------------------------+          |
                                                       |
                                                       |
                            +--------------------------+
                            |
                            |
                            v
   +-------------------+-------------------+-------------------------------------+
   | Extra Len(4Byte)  |  Extra Info(K/V)  |  Basic Info(Standard MySQL Packet)  |
   +-------------------+-------------------+-------------------------------------+

Header Format：
(1)Magic Num:
2个byte，协议magic，值为0x20AB，用于快速检测，防攻击, 区别zlib；

(2)version
1个字节，协议version号，目前版本号是0x20；

(3)Connection Id：
4个字节，server session id，集群唯一，认证成功后，server通过OK包带给client，用于
client/server session级别的双向校验，由于java client&&obproxy在建连接时有
clusterName校验功能，因此这个Connectin Id也可以看成多集群唯一。
目前server Connection id构成：

 |<---------------------------------32bit---------------------------->|
 0b   1b                             15b                              16b
 +----+------------------------------+--------------------------------+
 |Mask|          Server Id           |           Local Seq            |
 +----+------------------------------+--------------------------------+

MASK: 1 表示是server自己生成connection id, 0 表示是proxy生成的connection id(目前已经不使用)；
Server Id: 集群中server的id由RS分配，集群内唯一；
Local Seq: 一个server可用连接数，目前最大INT16_MAX;

(4)Request Id:
3个字节，client每次发送一个请求，Request Id递增，server回包时Request Id必须与请求的Request Id相同。
用于request级别的校验，初始值随机选取，当达到UINT24_MAX后，绕回0开始；

(5)Packet Seq:
1个字节，client每发一个packet，Packet Seq递增，response回复的Seq必须与Packet Seq + 1相等，
用于一个request内部，不同packet之间的序列校验；

(6)Payload Length:
4个字节，Payload Data的长度；

(7)Flag：
4个字节，reqeust与response的状态；每个bit代表代表一种状态；
+---------------+-----------------+---------------------------------------------+
| Flag & 0x0001 | ExtraInfoExist  |    0: doesn't exist; 1: exist               |
+---------------+-----------------+---------------------------------------------+
| Flag & 0x0002 | DataFlowEnd     |    1: data flow end; 0: data flow continue  |
+---------------+-----------------+---------------------------------------------+
|  other bits wait for extrend                                                  |
+-------------------------------------------------------------------------------+

(8)Reserved：
2个字节，待扩展；

(9)Header Checksum(CRC16)：
2个byte，crc16校验，包含mysql压缩协议的头部的7个字节；注：为0不校验；

Payload Format：
(1)Extra Info
当1 == ExtraInfoExist时，存在用于扩展，长度由Extra Length确定，由二元组
[key, value]组成，二元组的类型与ObObj类型对应，序列化与反序列方式与ObObj相同；
key，类型固定为ObVarcharType，并按照这种类型序列化与反序列化；
value，类型由type决定，按照Type类型序列化与反序列化；
每个二元组采用二进制形式紧密存储:
Extra Info一个使用的例子：
在全链路监控时，java client && proxy可以使用ExtraInfo将trace id传递给server；

(2)MySQL Protocol Data
mysql协议看成字节流，可能包含一部分、一个或多个mysql协议包；

Tailer Format:
(1)Tailer PayLoad Checksum (CRC32) 
整个payload的checksum，包含Extra Info（如有）和MySQL Protocol Data，CRC32校验，为0则不校验；