昨天我们学习了如何通过分区表来驾驭海量数据，并在课后留下了一个悬念：当集群资源不够用时，我们往里面加新机器，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 协议的多副本切换机制有关。）