本文转载自庆涛的一篇文章，会和大家聊聊和 OceanBase 数据库 POC 相关的内容，以及为大家分享一些数据库的运维经验。
最近一段时间，频频向庆涛大佬咨诹善道，不胜受恩感激。希望大家也都能从他的运维经验总结中察纳雅言，必能裨补阙漏，有所广益。
在文章开始之前，欢迎大家关注这个 OceanBase 开源负责人封仲淹（花名：纪君祥）的公众号 “老纪的技术唠嗑局”，会持续更新和 OceanBase 相关的各种技术内容。欢迎感兴趣的朋友们关注！
正文开始：
POC 全称 Proof Of Concept 。OB POC 是为了在真正上生产用之前了解 OB 的使用特点，包括开发和运维。所以 OB POC 做什么应该是看 OB 上生产后怎么用或者会遇到什么问题。这就要求先了解 OB，然而客户正是因为不了解 OB 才要 POC 。所以客户一般基于传统数据库的运维经验去设计 POC ，另外就是收集各个数据库厂商的 POC 经验文档然后糅合成一个 POC 标准文档。后者这种方式其实有点问题，不同数据库的功能原理不完全相同，各自的 POC 标准怎么能一定适应其他数据库呢。这种 POC 最后很可能演变为画一个表格给各个厂商打分的游戏。
本文要聊的 OB POC，是基于你确定要使用或者已经使用 OB 后给的建议，建议来自于我目前积累的 OB 运维经验。所以说 OB POC，其实也是在说 OB 日常的运维。这里说的 POC 既包括 OB 上线前的验证，也包括 OB 已经上线后但是要做一个从没做过的大动作或变更时在测试环境先做的验证。
OB 的部署架构
OB 的标准部署架构是一个三节点主集群，再可选附带一个单节点备集群。这里的主和备是运维目的上的人为定义，不是 OB 集群自身的属性（OB V4 版本以前的主备是集群层面，V4 以及以后的主备是租户层面。为了表述方便这里就将备租户所在的集群称为备集群）。这个备集群可以理解为传统数据库的 Dataguard 备库（如 ORACLE 的物理备库、MySQL 的从库）。虽然技术上是可选的，但我强烈建议带上，有备无患。OB 单机版部署时，更建议要带上备库。
所以标准的部署架构下 OB 需要 4 台服务器。如果客户只有三台的话，那可以考虑将备集群放到虚拟机里。但是虚拟机要保证必要的资源，且这个虚拟机上的 OB 备集群，只是一个灾备作用。
这里我依据经验给个虚拟机配置要求供大家参考：生产环境虚拟机资源最低要求：16C 64G内存，加 500G+ 的独立 SSD 盘。 用虚拟机是没有办法下的建议（官方文档不会建议让 OB 跑在虚拟机上，这部分内容只是作者的个人看法，仅供参考），这里有个重大风险就是虚拟化资源管理上采用了超分配的策略（CPU、内存和磁盘空间都超分配了，以及磁盘空间采取延迟分配策略等），这种对 OB 都是有害的。如果一定要虚拟机上跑 OB ，要确保给 OB 的资源是立即全额分配。小客户或者应用厂商在这个上面往往心存侥幸。以为将来数据库有问题了，找懂的人或者找原厂总可以解决。有这个想法的，建议这里部署架构验证环节多花点精力。
如果只有三台服务器的话，还有另外一个部署架构，就是主集群使用两台物理机才用 2F 1A 架构，备集群使用一台物理机部署单节点集群。主集群的 1A 是指仲裁服务（暂时只有商业版支持），这个可以用虚拟机，资源最低建议 4C 8G 内存 100G+ 空间。
然后机器的物理部署方式就看机房的个数了。如果只有一个机房，那主备集群尽可能散开到多个机柜。如果只有两个机房，则备集群单独一个机房。
如果是核心业务上 OB ，主集群架构建议是 2-2-2 ，这个比 1-1-1 的性能、高可用能力更强。
以上是生产的规划。
POC 阶段，大部分客户可能都没有充足的服务器资源。所以可以考虑用虚拟机。虚拟机最低要求 8C 16G 500G+ 独立 SSD 。虚拟机资源越低，OB POC 性能验证效果就越差。只要接受这个结论，那么用虚拟机做 OB POC 也无不可。大部分 OB 的运维功能还是能够验证。这里依然要注意虚拟机不要超分配，磁盘不要是机械盘。这两种情形下连基本的功能验证都会很卡，不是 OB 的原因，是虚拟机自身问题。
OB 集群创建任务
OB 的部署通过 OCP 去做。在 OCP 里创建 OB 集群时，会有一步要填集群参数。特别是跟资源（CPU、内存和空间）有关的参数。如果不设置，就会取默认值。如果没有为 OB 分配独立的数据盘和日志盘，将数据文件和日志文件混用的话，OB 集群可能会创建失败（最新的 OB 版本的参数也开始了当两个目录共用磁盘时的一些分配策略）。
有很多人不理解 OB 集群创建好后还没有数据为什么内存和空间就使用了很多，那么可以在这里通过调整参数反复创建 OB 集群来观察部署后的效果。这是验证，也是学习的过程。
参数设置好提交，OCP 会以任务流方式创建 OB 集群。OCP 的 OB 集群创建任务的每个子任务都有其作用。少数是框架必须的子任务，更多的是一些前期检查和准备,然后就是关键的步骤子任务。下面是简介：
-
Prepare cgroup environment：准备 cgroup 环境。
这里需要对 cgroup 有一些了解，然后根据任务日志里信息看看 OB 是怎么跟 cgroup 结合的。参考文末资源隔离文章。
-
Bootstrap ob: 集群初始化的关键步骤。一般要几分钟到十几分钟。
这一步如果失败了，必然是资源有不满足的地方或者参数有设置不合理的地方。很多人这一步出错就到论坛里提问，提问的时候建议把服务器资源情况（哪怕是虚拟机）、集群参数一并列出。另外排查一下基本的网络（节点间网络可通，防火墙关闭等），那么任务失败的答案自然就出来了。
-
Run io calibration：集群 IO 性能校准。早期版本这个是通过 FIO 和ob_admin的io_bench参数去做的，后期 OB 版本改为通过内部事件去做的。
通过 OCP 任务日志可知命令是 ALTER SYSTEM refresh io calibration 。事件结束时间跟磁盘 IO 性能有关。生产环境这一步必须成功，查看结果 GV$OB_IO_CALIBRATION_STATUS。 如果不成功说明磁盘 IO 很可能有问题。POC 环境，如果失败了，说明盘性能不行，后期性能测试就不要考虑了。那么就可以跳过这一步。
同样，生产环境如果运行后期怀疑磁盘 IO 性能有变化，或者磁盘 IO 有扩容（如云服务器扩容了或者物理盘加盘了），都建议重跑一次这个命令来检验一下最新的磁盘性能。时间选择在业务低峰期。在已经有业务的情况下跑这个作业也是有技巧的。首先要确保数据文件里有很多剩余空间，其次跑的时候可以按 ZONE 跑（提前把所有租户的主副本从该 ZONE 上切换走）。
POC 就需要验证上面这个观点是否如我所说。带着测试业务运行的情况下，跑一下 IO 校准,观察其对 OB 性能的影响。以及观察 OCP 里主机的 IO 性能监控指标的变化。
OB 租户创建
OB 租户的创建也是通过 OCP 操作。租户创建时要指定租户兼容模式、资源规格、字符集以及排序规则（MySQL租户下）等等。
租户的资源规格号称是可以弹性伸缩的。这里面是有多个场景需要运维提前掌握。
- 租户的资源规格多少合适
技术上租户的资源规格好像 CPU 最小可以是 0.5，内存最小是 1G 。但是这种规格的租户能力有多大呢？这里建议以 sysbench 测试不同规格的租户的能力，测试场景包括只读、纯写、读写混合等场景。最后出一个表格，几种资源规格下的数据库 QPS 、TPS 和 RT 和连接数能力等，以为业务参考。
这里关键的是最小资源规格。如果是有业务的，我建议不要低于 1C 2G，最好是不低于 2C 4G 。小租户的风险相比大租户要高一些，但这个不是由小租户规格独立决定的，往往是多种不利因素叠加在一起的。如数据量变大、访问量变大、小租户数量很多、集群升级等等。为什么要提这个呢？有些客户场景 OB 集群的机器配置还不错，客户又很节省资源，搞了很多小租户。这个并不是一个很好的选择。租户隔离是数据库隔离或 SCHEMA 隔离之外的一个手段。如果业务很多并且业务负载普遍不高，可以考虑用一个中等规格的租户然后按 database 去隔离不同业务，不要隔离得非常细，每个业务一个小租户（每个租户一个业务 DB）。
特别是 sys 租户的资源规格。如果集群资源很多，业务租户也很多，建议调大 sys 租户的资源规格。sys 租户关系到整个集群的稳定性，资源上不能太抠。经验是生产环境 4C 8G 起步。
- 租户的数量多少合适
租户的数量问题跟租户的规格问题其实是联系在一起的。单个节点上租户的数量多少合适官方文档并没有建议。技术上没有限制，只是使用上也不可能非常大。实际有客户案例发现，单个节点上租户数量过百后，在升级或者性能、稳定性方面不顺利。这个只是一个案例经验，并不是确定的会出现。理论分析，单个租户的数量多少也看单个节点的服务器配置、负载等。租户数量过百，那必然有很多租户规格很小，二者是联系在一起的。理论分析每个租户都有一定的内部管理成本（比如说每个租户还分了部分资源给一个 Meta 租户），肯定不是多多益善。这个不能跟单机起一百个 MySQL 实例进行类比使用。
控制业务租户的数量方法就是业务设计控制数据隔离的粒度是租户级别还是数据库级别。单个节点能承载多少租户也是需要自己 POC 验证的。这个也是考虑什么时候该做集群规模扩容的一个点。
- 租户的弹性伸缩
租户的弹性伸缩指租户资源规格可以在线调整。理论上是这样的，但是实际操作有更多细节要注意。租户资源的扩容可能打破集群各个节点资源使用率的平衡，引发新的一轮负载均衡。也就是可能有租户数据发生迁移。租户资源的缩容也是同理。当然前提是集群拓扑规模是不小于 2-2-2 的。这里并没有一个确切的公式告诉你某个租户扩容或缩容是否一定触发负载均衡，是要靠人分析各个节点资源使用率的变化，估计有多大可能性会发生迁移。 这个触发负载均衡的临界点在哪里是需要自己观察积累经验的。
租户扩容只要调大资源规格，但是租户缩容就不是这么简单。租户内存中还有增量数据，如果规格调整的过于小了，会导致缩容失败（会有报错提示）。所以缩容之前建议先发起租户合并。租户内存规格的缩小，会导致租户内部各个模块相应的内存份额都会变小，可能引来一些内存相关的报错。然而 OB 的内存报错代码都是统一的 -4012或 -4030 等，并不很直观的告诉你到底是哪块内存不够报错了。
所以，POC 的时候要多演练这个环节，为了模拟生产环境，POC 时的扩容和缩容都要在有租户负载的情况下进行（有充足的数据量和访问量）。这个是很有必要的。因为在生产环境，当你需要对集群或租户进行扩容或缩容的时候，你要能评估扩容和缩容实际的风险。文档描述是一回事，别人说的是一回事，都不如自己经历过的印象深刻。
OB 集群部署架构变动
OB 的灵活性很强。除了租户的弹性伸缩外，集群的部署架构也是可以在线调整的。比如说从 1F-1F-1F 在线变更为 1F-1F-1A 架构,又或者变更为 1F-1F-1F-1F-1A 架构。也可以在单机版（1F)和分布式版本(1F-1F-1F)之间变化。 此外还包括在线创建备集群或增加备集群等等。
通常来说企业客户不会有这种集群拓扑的变动需求。中小企业可能会有，往往是外部原因导致，比如说机房搬迁。OB 最近推出了单机版，这个客户量估计会增长很快，这么多的客户里必然有各种特殊的场景需求。比如说单机版的 OB 搬迁。搬迁方案有两种：一是单机版变分布式版本，然后再变回单机版；二是单机版本做主备集群，切换过去再删除一个备。
OB 故障和高可用
OB 标准的部署架构下，主集群的高可用通常就是关闭单个节点看看数据库有没有切换，业务能不能用之类。理论上如果多数派节点不可用了，OB 就不能用。POC 建议这两种都要看看表现。比如说看看当 OB 不能用的时候业务是什么表现。各种报错，那就看看这些报错信息的特点。这是为了将来万一 OB 真的发生不可用，能根据业务报错特点反推 OB 的状况。
导致节点故障的原因可以有很多。硬件故障、网卡故障、磁盘空间满、内存资源不足等等。当真的多数派故障了，除非你修复故障原因，这个集群是不可能拉起来了。尽管特殊情形下少数派副本节点也有办法强拉起来，但那个不是百分百的保证，而且操作起来非常麻烦。不要寄希望于这个。总有一部分客户心存侥幸，认为三节点的 OB 集群就表示会一直可用，或者出现不可用的时候原厂会有办法拉起来。所以，POC 的时候可以感受一下。
真正保险的做法是为 OB 集群做一个独立的备集群（备租户），这就是传统的 Dataguard 方案。一旦真的主集群不可用了，DBA 就对 OB 租户发起故障切换（FAILOVER)。这个是手动操作，具体要多久取决于备集群状态、DBA 经验等。单个租户的故障切换可以在 OCP 里操作。但是如果租户数量非常多，这个就很耗时了，需要写脚本批量去切换了。所以 OB 租户的故障切换也是需要在 POC 中积累经验的。
再回到单个集群内的高可用，目前 V4 版本声称的 RTO 指标约 8 秒。这个指租户内的数据切换指标。当租户节点规模很大（或者日志流很多的时候），并不一定是所有数据的切换都是 8 秒（有快有慢）。此外，业务应用的恢复时间还会比数据库恢复更长。在这期间，也可能出现部分数据恢复了，部分还没有恢复（分布式数据库这点跟传统集中式数据库 ORACLE 很不一样）。业务会收到各种报错信息，夹杂着也有成功的信息。对于业务来说，判断恢复的时间点会复杂一些。是从第一个恢复日志算起还是从最后一个恢复的算起。生产环境发生故障，在恢复后写故障报告的时候就要定这个时间。很是费精力。
此外还有一类特殊的故障也建议 POC 的时候做。比如说直接拔硬盘、用命令让 RAID 卡放电、删除 OB 数据文件目录或日志目录、将虚拟机挂住（PAUSE，尽可能模拟服务器 HANG)。重点是观察 OB 和业务的表现。对于数据文件或日志目录被误删除，基本就意味着这个节点废了。那么如何快速重建 OB 节点也是需要验证的。
OB 备份和恢复
OB 备份一定要有，那是应对故障最后的保障。有备无患，无备等死。 OB 备份文件一定要放到 NAS 或 对象存储里，不要放在 OB 本机。否则，本机起不来，备份也用不上。如果没有 NAS，用独立的服务器做一个 NFS Server ，输出一个 NFS 目录到 OB 节点，也是可以的。
OB 的备份文件目录要研究一下，跟传统数据库备份目录很不一样，并不是想象的每个备份一个独立的目录。OB 的备份包括数据目录和日志目录，可能散落在多个地方，复制起来很不方便。一般还原的时候最好是原始的 NFS 路径还原即可。客户场景可能有将 OB 生产备份复制到测试环境的需求，做是可以做的，可能需要找到复制多个备份目录的文件，还原的时候指定路径还有讲究。这个需要演练一遍。
备份恢复还有个场景是业务往往误删除或更新了某个表，只想恢复某个表。这个 OB 也是支持的。恢复的时候需要一个临时租户过渡。所以恢复的时候 OB 集群还需要有一定剩余资源。
NFS 作为 OB 备份路径是常用用法。不过这个 NFS 目录的权限可能会被用户搞乱。正常的时候备份目录的属主和权限如下：
[root@RS-OBDB-P1 obcebackup]# df -h |grep backup
10.*.*.50:/DBbackup/RSOB 70T 20T 50T 29% /data/backup
[root@RS-OBDB-P1 obcebackup]# ll /data/backup/obcebackup
总用量 12
drwxrwxr-x 3 nfsnobody nfsnobody 3 5月 7 2024 cluster
drwxr-xr-x 3 nfsnobody nfsnobody 3 4月 23 22:01 cluster2
drwxr-xr-x 4 nfsnobody nfsnobody 4 6月 19 2024 odcmetadb_backup
挂载目录是 /data/backup，则 OB 备份目录用下面的二级子目录 /data/backup/obcebackup 。属主和权限第一次配置成功了后面就不要动。备份目录也最好是后面不要改了，改动往往就会出错，最后可能导致 OB 备份也不正常。OB 备份常见问题有权限问题、空间容量问题。
OB 备份介质最好的选择是对象存储 OSS 。对象存储就是手动访问的时候没有文件系统那么方便，第一次配置也略麻烦一些。这些在 POC 的时候建议都调试通过。国产的数据库备份产品（如爱数），如果兼容 OB ，也可以研究一下其备份原理。一般使用的是 OSS 对象存储。
备份对 OB 读写影响有多大。如果想知道也在 POC 的时候看看。在生产环境，特殊情形下是要在有业务负载的情况下发起备份。如重大变更前的数据备份。 OB 的备份现在也支持对备库（备租户）做备份。因此如果特别担心影响的时候，也可以备份备租户。前提是确认备租户的延迟很小。
OB 负载测试
以上所有的 POC 建议都建议在 OB 有负载的情形下做。 要给 OB 加负载，建议跑 sysbench 和 benchmarksql tpc-c 。
sysbench 默认的连接测试方法可能会在 OB 出错的时候就停了，此时需要将 OB 报错号码放到 sysbench 的一个忽略错误的参数里，这样 sysbench 就可以实现自动重连效果。 benchmarksql tpc-c 里面是有循环请求的能力。即使 OB 有报错它还会重试继续运行。当然也可能个别错误会导致 benchmarksql tpc-c 整体退出。此时调用 benchmarksql 测试用 SHELL 的 for 循环方法去做，就可以模拟业务的不间断访问。
测试的并发数决定了 OB 负载的压力，这个要适当。不能太小，也不能太大。并发数太大，超出 OB POC 机器的能力，OB 很卡，也还是会有一些不必要的异常干扰。
未完待续
越写越长，看来一篇讲不完，就拆成多篇吧。下一篇聊跟 SQL 有关的 POC，会第一时间在 OceanBase 社区公众号 “老纪的技术唠嗑局” 中更新，欢迎大家关注~