大部分人部署 OB 后，都会碰到 OB 占用很多内存和空间问题，很不解也不好解释。内存过大还可以后期缩容回去，但是磁盘空间就没办法缩容。本文主要是介绍这个 OB 磁盘空间分配原理和回收方法，属于 OB 运维中的“金刚钻”技术。

近期 OB 4.3.3 版本发布，功能亮点之一就是 SQL+AI，传统的业务场景不大用到这个功能，所以看着很陌生。OB 社区团队将在本周三（明天）在合肥举办线下活动，有多个 OB 客户分享这方面的实践经验，详情请看文中活动海报。

OB 空间资源分配原理

OB 架构独特之一是多租户，设计思想是在多台无共享架构下的 PC 服务器上运行 OB 进程,攫取主机的主要资源组件为一个数据库资源池（集群），然后从集群里分配自定义的资源以租户（实例）形式给用户使用。所以 OB 部署后即使没有业务也会占用大量内存和磁盘空间。内存资源的使用以前已经介绍过原理，本文主要介绍空间资源。OB 进程（名字：observer）对空间资源的使用是分为三部分：运行日志、数据文件、事务日志文件。

OB 进程运行日志。

默认在 OB 软件安装目录下的log里。企业版默认路径是：/home/admin/oceanbase/log 。OB 进程的运行日志（observer.log、rootservice.log）内容非常多，根据日志级别可以调整。日志内容主要是面向 OB 内核开发的，可读性很差，还占用空间。生产环境要为此预留 300G 的空间，不然出问题的时候查不到日志（被清理了）就很麻烦。随着 OB 版本的迭代，OB 逐步在丰富这个日志文件的管理策略。除了可以控制日志级别、日志数量，近期版本还可以对过往日志进行压缩（压缩比10:1）。

上面是一些关键配置供参考，有兴趣的可以查阅官网。可以在进程初始化时指定，也可以事后修改。除此之外，OB 进程近期还效仿 ORACLE 推出面向普通用户的 alert.log，位置在log/alert/ 下。这个日志确实清爽很多。

OB 数据文件

OB 进程只有一个数据文件，文件的大小就看你给的文件系统有多大空间，从几个 G 到几十 T 都行。OB 早期研发设计的时候觉得一个文件编程方便。现在看来对运维也非常方便。不管你的 OB 是怎么部署，OB 在每个节点上的进程只有一个数据文件。这个文件的大小通过三个参数控制：

datafile_size:数据文件初始大小。如果你不希望 OB 一开始就占用很多空间，这个值就不要太大。生产可以 100G 起步。
datafile_disk_percentage:数据文件初始大小占文件系统可用空间比例，早期 OB 版本这个参数默认 90% 。这个参数跟上面参数二选一。如果两个参数都不设置（为0），那么 OB 又取了 90% 的默认值。这就是为什么大部分人部署 OB 后空间使用很大导致剩余空间不足。
datafile_next：数据文件增长一次增长的大小，默认是 0 表示不增长。这个还是要设置的，一般设置为 1G 就行。
datafile_maxsize：数据文件最大大小，数据文件可以增长，但不能无限制增长，一定要设置一个文件系统能接受的大小。这个参数可以变大或变小，但是不能比当前的数据文件大小要小。也就是说，OB 的数据文件实际大小只能变大不能变小。

最佳实践：OB 进程启动的时候设置 datafile_size 初始大小（如 10G~100G），设置数据文件自增参数 datafile_size（如 1G~10G），设置数据文件最大大小 datafile_maxsize（如 500G~20T，在文件系统空间可以接受的范围内）。

当 OB 数据文件增长后，就不能通过调整数据文件参数来缩小其大小，后面会介绍如何对数据文件进行缩容。

OB 事务日志文件

OB 的其他日志文件还有slog和clog。slog 是数据文件的索引，而clog是跟 OB 的事务有关，也是传统意义上的redolog。OB 从1.x~3.x，所有租户的事务日志是混合在一起的，OB 4.x 推出日志流LS功能后，事务日志按租户存放，并且日志流的粒度从以前的分区（分区组）扩大到近似租户粒度（每个租户下默认内部表一个日志流，业务表一个日志流）。日志流起始可以理解为 OB 数据同步方向的最小单位。所以当 OB 将主可用区（primary_zone）从单zone变更为多zone后，就会多出 1-2 个日志流。当使用复制表后，还会额外多出一个日志流（复制表的同步策略不是 Paxos 多数派同步，而是全同步）。

OB 4.x 后 OB 进程总的事务日志空间是通过下面两个参数控制：

log_disk_size : 进程初始化后会预分配的日志目录空间大小（可以立即为日志资源池）。具体形式就是目录下/data/log1/obdemo/clog/log_pool有很多固定大小（64MB）的日志文件。
log_disk_percentage : 作用跟上面一样，只不过是按文件系统可用空间比例控制的。OB 在创建租户的时候，租户要指定 log_disk_size，其大小就是从进程参数设置的大小里分配。如果进程的日志空间资源不足，租户资源池就分配报错。

OB 租户在拿到确定的日志空间后，就在租户内部循环利用这个空间。OB 的 clog 内部使用可以循环覆盖。不过也存在一些场景下事务的 clog 由于还被需要不能被覆盖。这个原理很好理解，场景却非常多。这里就不列举了。一般来说尽量减少大事务、OB 每日合并和备份要正常、设置适当的数据文件转储参数。

OB 租户的事务日志空间是可以在线调整的（变大或变小）。变小的时候，租户会将这部分空间归还给集群的日志空间池子。变小的前提也是对应的clog可以释放掉。在某些特殊场景下当租户某些事务的clog不能释放时，这个变小会失败。

最佳实践：租户事务日志空间的大小建议为租户内存资源的 2~4 倍（内存越大，倍数可以越小），这样租户的事务很繁忙的时候瓶颈不会出在 clog 空间上。这个空间不要太小（比如说十几 G，这个就有点抠门了。）

空间分配实践

OB 部署的时候，上面三个文件建议使用独立的文件系统目录。有的时候交付会说用不同的盘，盘最终也是要格式化为文件系统并挂载。所以这里说的是独立的文件系统。目录最佳实践如下：

/home/   -- 不同的盘或者跟 OS 一起的盘
     |-  admin/oceanbase/log         -- 运行日志空间
     |-  admin/oceanbase/store/obdemo/
                                 |- sstable -> /data/l/obdemo/sstable     -- 数据文件空间
                                 |- slog -> /data/log1/obdemo/slog
                                 |- clog -> /data/log1/obdemo/clog        -- 事务日志空间
/data/1        --- 不同的盘
/data/log1    -- 不同的盘

如果数据文件跟事务日志文件共用一个文件系统，在空间的分配策略上要先考虑事务日志文件，然后约束数据文件的最大大小，确保数据文件空间的增长不会导致事务日志文件无法分配必要的空间。

如果一开始没有控制好，导致数据文件很大了，要缩容这个数据文件的方法就是重建这个节点。通常通过 OCP 也可以重建一个节点。这个任务会有点长（连软件一并重装了，启动参数沿用集群当前参数）。如果 OCP 任务还出错了，运维人员并不一定知道怎么处理，而此时数据副本三缺一却是有点危险的事情。

所以，本文后面要介绍的是手动快速重建三副本架构 OB 集群的一个节点（五副本同理，不适合单副本架构）。这个方法利用到 OB 部署最基本的原理。所以，即使出错也是能快速应对。这个基本上是 1-1-1 OB 集群里最快的重建某个 OB 节点的方法。当然，这种方法也有一定操作风险，重建节点的时候三副本缺一个，不再有高可用能力。如果集群架构时 2-2-2 ，操作起来会更稳妥一些，但是这个会触发 OB 内部两次数据迁移的过程。

所以，这个 OB 节点数据文件缩容的方法属于高级技巧，谨慎使用。在介绍之前还是先介绍一下 OB 集群的手动部署过程和原理。

OB 集群手动部署

从 OB 1.0 版本开始我就介绍过 OB 集群手动部署过程，到 2.0,3.2,4.3 我依然还经常提手动部署的方法。（文末有所有版本手动部署文章链接。）其原因是 OB 现在的自动化部署方法有多个，企业版就是 OCP，社区版有 obd 、docker、OCP 等等。自动化部署工具使用起来顺利的话很方便，但是对于部署原理不会过多介绍。如果工具出现异常，很多人面对报错手足无措。这其中有很多表面上看是资源准备问题，其实就是用户对 OB 集群部署原理的不了解问题。

像 OCP 本身又很重，一般的用户不一定有很富裕的资源能练习 OCP 的部署。在资源很低的情况下，使用 OCP 很容易出现异常。OCP 部署 OB 的时候，用户一样需要指定很多参数。如果不指定，OCP 会使用默认的参数部署 OB 。用户资源不足的情况下，这个部署容易失败。即使部署成功了，也会出现上面说的空间被占去大部分这种情形。

所以，很多人就会传 OB 部署门槛很高，OB 学习门槛很高之类的。个人认为，只是学习方法不当而已。方法到位的话，5分钟就可以部署一个单节点的 OB 集群，三节点也差不多，10分钟足够。而掌握这个手动部署原理后，再去用 OB 其他产品部署 OB ，就很容易理解其原理了。

下面是手动部署过程介绍。

前面的依赖软件准备、操作系统内核参数、会话参数、用户设置、文件系统等都参考官网文档设置。手动部署分为三步。

软件以及目录准备

软件可以使用 RPM 安装到默认目录 /home/admin/oceanbase ，也可以手动解压缩 RPM 包到指定位置。这里展示后者。

rpm2cpio oceanbase-4.3.2.1-101010012024091010.el7.x86_64.rpm | cpio –idmv
mv home/admin/oceanbase /home/admin/ && chown -R admin.admin /home/admin/oceanbase

mkdir -p /home/admin/oceanbase/store/obdemo
mkdir -p /data/1/obdemo/{etc3,sstable} /data/log1/obdemo/{clog,etc2,slog}
ln -s /data/1/obdemo/sstable /home/admin/oceanbase/store/obdemo/sstable
ln -s /data/log1/obdemo/clog /home/admin/oceanbase/store/obdemo/clog
ln -s /data/log1/obdemo/slog /home/admin/oceanbase/store/obdemo/slog

OBServer 进程启动方式

下面是单副本OB 集群的启动方法，如果是三副本的话，相关参数里会包含三个节点 IP，这个参考以前的文章。

cd /home/admin/oceanbase && bin/observer -r "10.0.0.65:2882:2881" -p 2881 -P 2882 -z zone1 -n obdemo -c 20240928 -l ERROR -d /home/admin/oceanbase/store/obdemo -I 10.0.0.65 -o "__min_full_resource_pool_memory=1073741824,datafile_size=10G,datafile_maxsize=150G,datafile_nextsize=1G,log_disk_size=50G,enable_syslog_recycle=true,memory_limit=24G,system_memory=2G,cpu_count=16,enable_syslog_wf=False,max_syslog_file_count=50"

这里我设置了很多参数，跟资源有关的。其目的就是展示如何在启动参数里精确控制 OB 进程的内存、空间资源等。

OB 集群初始化（bootstrap）

当进程启动成功后，可以使用 mysql 通过 2881端口连接。

mysql -h127.1 -uroot -P2881 -p -c –A
set session ob_query_timeout=9000000000; alter system bootstrap ZONE 'zone1' SERVER '10.0.0.65:2882';

单个进程大概 40s 内能初始化完毕，三副本集群看网络性能可能在 60s~200s 以内完成初始化。只要命令不报错，执行下面 show database 查看到了 oceanbase 数据库就表示集群部署成功。

上面部署好了 OB 集群，如果是三副本架构，还需要部署一个 OBProxy 。

OBProxy 手动部署

部署 OBProxy 的原理也很重要，很多人会在 root@proxysys 和 proxyro@sys 密码上碰到过问题。OCP 里接管一个 OBProxy 的时候往往会要输入这个密码，而用户不一定记得这个密码是什么。OCP 里用户如果没有指定这个密码，OCP 就会用随机密码去填充，这个给后期运维留下一个风险。尽管 OCP 说自己会保存这个密码。但是如果以后 OCP 异常了，整体被删除重搭了，再接管老的 OBProxy 就会碰到密码问题。也有人会说，你为什么要删除 OCP 呢？这个就因人而异了。大家对国产数据库及其平台的功能了解不一，使用规范风格也不尽相同。很容易用着用着就不规范操作了，最后 OCP 出问题了。出问题后总是要解决的，OB 社区版还没有原厂服务就要自己解决。有同感的欢迎留言。

所以，自己解决问题的前提是对 OCP 、OB 以及 OBProxy 的功能原理非常了解。当平台出现异常的时候，就要手动介入处理。这一步我们就看看 OBProxy 的部署过程中是怎么创建这两个用户和密码的。

OBProxy 的部署也细分三步：