深入浅出 OceanBase 运维之弹性扩缩容

2021 年 12 月 23 日
本文字数：1753 字
阅读完需：约 6 分钟

可扩展性是数据库系统一个重要的特性，架构师们动辄提及的 scale up 和 scale out 是两种常见的扩展方式。

前者指纵向扩展，主要基于现有的存储系统，通过增加存储容量和计算容量来满足容量扩展的需求，这种方式的缺点是价格昂贵。例如 EMC 的高端存储和 IBM 的服务器系列，并且受限于临界区，很难做到线性扩展。

/ 传统关系数据库：垂直扩展 /

后者指横向扩展，通常以节点为单位来扩展，从应用的视角来看仍然是一个单一的系统。扩展的节点是否包含存储又分为 Share Storage 和 Share Nothing，Share Storage 例如 Oracle RAC，Share Nothing 例如 Google spanner。Share Storage 会有多点写冲突的问题，Oracle RAC 通过 Cache Fusion 来解决，Cache Fusion 会降低写的线性扩展性。Share Nothing 则会比较彻底，能够带来非常好的线性扩展性，当然也会带来分布式事务的问题。

/ OceanBase ：水平扩展 /

综合来看，scale out 更加符合“容量自由”的理念，可以按需购买，伸缩自由，从而降低 TCO。

OceanBase 如何实现自身扩展性？

那么以“线性扩展”著称的 OceanBase ，在不同条件下是如何实现自身扩展性的呢？

比如：当计算资源不足，部署集群后续考虑容灾部署，单机故障后如何替换？网络调整需要调整 IP 段如何实施？机房搬迁如何应对？大促前后如何降本增效？

其实以上的运维都涉及 OceanBase 集群/租户扩缩容和内存的调优，这里让我们具体来看看以下几个更实际的场景和对应的解决思路。

业务增长后，集群如何快速响应业务需求?业务量增长后原有的集群无法满足当前的需要，比如计算资源或者存储资源不足，该怎么办？

📍 解决思路：

OceanBase 数据库独创的总控服务和分区级负载均衡能力使系统具有极强的可扩展性，可以在线进行平滑扩容并且在扩容后自动实现系统负载均衡，对应用透明，确保系统的持续运行。在此过程中，我们需要做的是对 server 规格升级，可以以 zone 为单位，滚动升级每个 zone 下 server 节点的配置，做到在线无缝地完成集群的扩容。

别怕！本期直播来帮忙！你的困惑“有救”了！

面对业务峰值，OceanBase 如何在保证性能的同时又能有效降低成本？

📍 解决思路：

在 618、双 11 等大促特殊时期，电商 APP 等业务量是日常情况的数倍，业务系统需要在大促前后进行升降配。我们会提前评估出扩容后的集群规模，以 Zone 为单位，滚动给每个 Zone 添加同等配置、同等数量的 server 节点。此外，我们还可以从 3 副本扩容到 5 副本，将一部分耗时久的或者降级后的操作调度到只读副本上。