本文依然是一个严谨的技术文章，会运用此前分享的多个OceanBase 技术知识来反向探索OceanBase公有云租户实例的特点和背后的细节。当然，研究细节只是为了加深 OB 原理的理解，不是刻意找茬。
购买路径：【OB官网】-【产品】-【OB Cloud】，选择【免费试用】。这里会有个选择问题。
个人用户试用如果选择阿里云，版本是 3.4；选择华为云版本是 4.2 。这里我选择了阿里云。3.4 版本估计是公有云特有的版本，主要功能跟企业版 3.2 一样，可能会有一些特殊的功能（这个以后再探索）。所以后面提到的一些功能注意主要是 OBV3 的功能。
接下来就是云数据库的购买界面。
在这个试用实例的确认页面里有个细节就是这个实例节点数是 3个，但只有两个数据全功能副本。3个节点是说这个实例会占用 3 个 ECS（但不是独占）资源，2 个全功能副本，那么还有一个是日志副本。所以这个租户实例的架构是 2F1L （在 4.2 版本里对应的架构师 2F1A）。这个租户实例是从已有的 OB 集群里分配出来的一个租户，也不是独占集群。有这个设计也降低了 OB 运营推出免费实例试用的成本压力（但并不够，后面还有其他招数）。
数据库实例购买成功后进入【产品控制台】。这个模块很重要，等同于公有云版本的 OCP 了。
看起来功能比线下的 OCP 功能要少很多，也是正常的。毕竟租户级别的实例就不需要关心主机、软件等。不过看这个页面，概念【实例】和【租户】同时出现了。在线下部署介绍时，实例和租户通常等同使用。在云产品里，实例有自己特有的含义，代表的就是一个产品实例，如 OB集群实例、OB租户实例。企业用户一般购买的是集群实例，在控制台里看到的也是【实例】，后面那个【租户】就是 OB 里常说的租户。因为我这里购买的是租户实例，所以不存在再创建租户这个动作了。
接下来就看租户实例的信息。
上面展示租户实例的基础信息、性能信息以及连接信息。最重要就是这个连接信息。云数据库都有一个内网连接地址和公网地址。如果你此前还购买了统一区域的 ECS，那就用内网连接地址。公网连接地址是要占用公网 IP 和带宽资源的，默认没有开通。需要点击一下【开通】。后面读写数据测试的时候会有公网读写流量，这个成本 OceanBase 默默的承担了（👍）。
连接 OB Cloud 租户实例
云数据库公网链接地址开通后，可以 ping 域名以及 telnet 域名 和 3306 端口。这里试用的都是 MySQL 租户，公有云提供的连接端口是 3306 ，方便传统 MySQL 客户使用。在后端 OBProxy 依然是有的，监听端口推测依然是 2883（默认的）。这个公网连接地址推测是挂在阿里云 SLB 上的一个 VIP，后端对应多个 OBProxy 。也可能实际链路更复杂一些，都是为了网络安全。
现在还不能直接连接，先需要为租户实例开通白名单。默认的白名单只有 127.0.0.1 。首先要说明的是这里的白名单不是 OB 租户里的那个白名单概念，而是公网连接 IP 的白名单，是云的网络产品的基本功能和需求（为了安全）。白名单就是客户端的地址，严格来说是公网出口地址（除非客户自己跟阿里云 VPC）有专门的通道。普通用户就需要查询一下自己的公网 IP 了。有多个方法，推荐命令行下这个方法。
C:\Users\MQ>curl cip.ccIP : 183.157.222.114地址 : 中国 浙江 杭州运营商 : 电信数据二 : 浙江省杭州市 | 电信数据三 : 中国浙江省杭州市 | 电信URL : http://www.cip.cc/183.157.222.114
linux 服务器也是这个命令。
白名单一定要配置对，否则后面在客户端是连不上 OB 数据库的。然后就是配置客户端的数据库连接了。
这里注意，使用 dbeaver 第三方工具连接 OB MySQL 租户的时候，可以使用 MySQL 驱动或者使用 OB 官方驱动。建议是 OB 官方驱动，后面在观察 OB 客户端会话 IP 的时候就能看到这个区别。这个在以前的文章《OB 数据库全链路分析案例：租户/用户白名单机制》里也详细介绍过。
探索 OB 集群信息
虽然知道购买的是 OB 租户实例，只是某个集群的一个租户。那么从这个租户里能否看到集群的一些信息呢。
SELECT tenant_id, tenant_name, ZONE, unit_config_name, resource_pool_name, svr_ip, svr_port, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb, round(min_memory/1024/1024/1024) min_mem_gb,max_iops,min_iops,round(max_disk_size/1024/1024/1024) max_disk_size_gbFROM gv$unit;
这个可以看到租户资源所在的三个 Zone 以及 IP 名称，也就是前面说的 3 个节点信息。其中 cn-hangzhou-i-z2 上节点的资源规格要小一些（只有1C2G），从名字 unit_config_name：obmtlk5bt7gt93a0_unit_log 看是一个日志副本。IOPS 是 1000，数据盘 500G。在线下，我不建议开启租户 cgroup 资源隔离，都是自己的业务，资源不用卡得那么死。在云数据库里，IOPS 隔离就非常有必要了，不然不同租户实例存在互相抢资源的可能。
OB 从 3.2.4 版本引入参数 enable_cgroup 用于启用 cgroup 做租户间的资源隔离，具体可以做 CPU、内存、IOPS 和 IO 吞吐隔离。在租户实例里可以看到这个参数也启用了。实际上租户实例里可以看到很多参数。
SHOW parameters WHERE name IN ('enable_cgroup','datafile_size','backup_dest_option','major_compact_trigger','cpu_count','memory_limit','minor_compact_trigger','minor_freeze_times','freeze_trigger_percentage','merge_thread_count','disk_io_thread_count','sys_bkgd_net_percentage','data_disk_usage_limit_percentage','sys_bkgd_io_high_percentage','all_server_list','major_freeze_duty_time','enable_rebalance','enable_rereplication','resource_soft_limit','resource_hard_limit') ;
上面这些参数在平时的运维中都有用到，只不过在云数据库里，有些运维工作不需要用户做。不过我们还是有必要借参数值去了解云数据库背后集群的运维特点。
参数 all_server_list 里列举了这个集群所有的 OBServer IP，这是在租户实例里能看到唯一的集群的完整的 IP 信息列表。数了一下有 20多个节点。集群 2F1L 架构的话，第三个zone3 的节点数量不需要跟其他节点数量一致。
参数 resource_hard_limit 值为 400 表示超卖比例是 4 ，具体效果相当于集群持有的 CPU和内存资源的总数是 OBServer 进程从主机那里获取的 4 倍。这个因为是试用实例才这么设置，是降低运营成本的第二个关键技术，也只有 OB 有这个设计。从原理上分析 OB 的这个超卖设计对 CPU 使用没有大的问题，对内存分配是可能有问题。如果所有试用用户的租户实例的实际内存超出了物理节点能提供的内存资源之和时，那租户实例之间可能会出现内存挤占或者内存无法分配的报错。CPU 的超卖就没这个问题，因为除了 OS 外，其他进程 cgroup 以及 OB 都不能独立的控制 CPU 的配额。
参数 datafile_size 有两个节点是 489G 有一个节点是 96G 。后者是日志副本，不存储数据，所以磁盘给的很少。OB 目前版本应该还不能做到租户数据空间的隔离，所以所有租户共享数据文件的空间。整个集群的数据文件大小也就 500G 。不过由于 OB 数据有很高的压缩比，实际可以容纳的业务数据量可以到达 1-2T 。所以这个试用实例也别当真导入 500G 数据。如果大家都这么玩的话，可能会在写入的时候出现 Server out of disk 报错。
参数 freeze_trigger_percentage 内存转储阈值是 60%，memstore_limit_percentage增量内存比例是 50% 。
参数 minor_freeze_times 值是 1000. OB V3 版本里租户不能独立发起合并（major freeze）。所以任意一个租户的转储次数到达这个参数值后将会触发整个集群级别的合并。试用实例 4G 内存规格，如果持续做大批量数据导入，理论上是可能触发这个集群合并的。不过 CPU 规格很低（1C）加上还是超卖稀释（指峰值能力）过的 1C，也很难具备这么高的内存写入能力。
参数 backup_dest_option 为空。V3 版本 OB 备份是集群粒度的。试用实例也不提供备份能力。
此外，还可以看租户特有的参数。
SELECT name, data_type, SECTION, SCOPE, value, edit_level FROM oceanbase.__tenant_parameter;
这两个参数也很重要。前一个是查询 SQL 是否独立开启 OBProxy 的事务路由特性。这里是 true ，建议改为 false。OB 4.2 版本这个参数都默认是 false 了。这个原理在以前的文章里介绍过。后一个参数是租户 MEMTABLE 内存写入限速参数。
OB 租户实例测试
接下来对这个 OB 租户实例做一个 TPC-C 测试。通过 BenchmarkSQL 初始化 100 仓数据，然后做性能测试。这个结果就看看，目的不是跑性能。
接下来做连接有关的有趣的测试。连接数据库，看看客户端会话。
SELECT usec_to_time(request_time) req_time, svr_ip,sid, client_ip,user_client_ip,tenant_id,tenant_name,user_name,db_name,sql_id,plan_id,plan_type, query_sql, elapsed_time,get_plan_time,queue_time,execute_time,affected_rows+return_rows total_rows,eventFROM oceanbase.gv$sql_auditWHERE is_inner_sql=0 AND user_name <> ''AND user_name IN ('mq')AND query_sql LIKE '%20240721%'ORDER BY request_time DESC ;
从 SQL审计记录看出：
SQL 被 SLB路由到的 OBProxy IP（client_ip）：192.168.40.24
SQL 被 OBProxy 路由到的 OBServer IP(server_ip) ：192.168.40.24
真实的客户端 IP（user_client_ip） ：前一条是客户端的公网IP，后一条是内网IP。
这个真实的客户端 IP 主要是用于租户白名单里。不过由于多个应用可能会同时使用 OB 和 MySQL 的驱动，导致 OB 看到的客户端 IP 有很多种。所以，实际运维通常不在租户里设置白名单（要设置一大串。。。）。在公有云里，白名单只在 VIP 级别设置，更安全更灵活。这个 OB 租户实例的白名单变量值就是默认不限制（值为 %）。
(4G+4G+2G) * 0.5 * 1024M/G = 5120M5120M*0.6=3072M。
SELECT t1.tenant_id, t2.table_name, t1.partition_id , t1.partition_cnt , t1.svr_ip , t1.unit_id , t1.`zone` , t1.ROLE, t1.row_count , round(t1.data_size/1024/1024) data_size_mb ,round( t1.required_size/1024/1024) required_size_mb , t1.data_versionFROM `__all_tenant_meta_table` t1, __all_table_v2 t2WHERE t1.table_id MOD (1<<40) = t2.table_id AND t1.tenant_id= effective_tenant_id()AND t2.table_name LIKE 'bmsql_oorder'ORDER BY t1.table_id, t1.partition_id, t1.ZONE;
总结
文中提到的 OB 技术原理请参考以前的文章：
