每天10分钟学会OceanBase系列（Day 6）：在线扩容与数据自动均衡，让集群“越用越聪明”

昨天我们学习了如何通过分区表来驾驭海量数据，并在课后留下了一个悬念：当集群资源不够用时，我们往里面加新机器，OceanBase 是怎么把数据自动"搬运"过去的？今天我们就来揭秘这个让 DBA 彻底告别半夜加班的"黑科技"------在线扩容与自动负载均衡（Rebalance）。

核心原理：RootService 的"智能调度"

在传统分库分表架构下，增加节点往往需要 DBA 手动编写脚本去拆分和迁移数据，不仅容易出错，还会导致业务抖动。而在 OceanBase 的原生分布式架构中，集群内置了一个强大的"大管家"------RootService。

当你通过命令将新的物理机（OBServer）加入集群，并扩充了租户的资源池（Resource Pool）后，RootService 就会接管一切。它会自动触发 Rebalance（数据均衡）过程，将部分数据分区（Partition）从负载较高的旧节点，平滑地在线复制到新节点上。整个过程对应用完全透明，无需停机，也无需修改任何业务代码。

10分钟实操：模拟一次水平扩容

假设你的集群已经准备好了新的物理机（IP: 192.168.1.100），只需在 root@sys 租户下执行以下 SQL，即可完成扩容：

复制代码

-- 1. 将新机器添加到集群中
ALTER SYSTEM ADD SERVER '192.168.1.100:2882' ZONE 'zone1';

-- 2. 扩充资源池，让新机器承载更多数据
ALTER RESOURCE POOL my_pool UNIT_NUM = 2;

执行完第二条命令后，OceanBase 就会在后台默默开始"搬家"。你可以通过以下视图实时观察数据均衡的进度：

复制代码

-- 查看当前集群的负载均衡任务状态
SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE job_type = 'REBALANCE_TASK';

💡 扩容避坑与最佳实践

虽然扩容很丝滑，但在生产环境中仍需注意以下两点：

扩容耗时与数据量成正比：Rebalance 过程涉及大量的数据网络传输和磁盘 I/O。如果集群数据量达到 TB 级别，均衡过程可能会持续数小时。因此，建议在业务低峰期触发扩容。
跨机执行与表组（Table Group）优化 ：如果你的业务经常需要跨多个分区进行 JOIN 查询，数据分散在不同机器上会增加网络开销（RT 升高）。此时，可以利用 OceanBase 的**表组（Table Group）**特性，将存在关联关系的表绑定在一起，确保它们的主副本始终落在同一个节点上，从而将分布式查询降级为高效的单机查询。

今日小结

今天我们见证了 OceanBase 真正的"弹性"魅力。通过 RootService 的自动调度，集群能够像细胞分裂一样自动吸收新增的硬件资源，并自动完成数据的重新分布。这让数据库真正具备了与业务共同成长的弹性管理能力。

💡 课后思考

既然 OceanBase 支持无缝的水平扩容（Scale-out），那如果我想给现有的某台物理机升级 CPU 和内存（垂直扩容 Scale-up），OceanBase 又是怎么做到不停机、不丢数据的呢？（提示：这与 Paxos 协议的多副本切换机制有关。）