一、为什么要扩容OceanBase集群
当业务数据量像春天的竹笋一样疯长时，原先的OceanBase集群可能就会像小号行李箱塞满冬装——明显不够用了。这时候扩容就成了必选项，通常出现在以下场景：
- 磁盘空间剩余不足20%，监控天天告警
- CPU持续高于70%，查询响应明显变慢
- 计划新增业务模块，需要提前储备资源
举个真实案例：某电商平台大促前，通过SHOW STATS LIKE 'storage'查看到单节点数据量已达12TB，果断决定将3节点扩至5节点。
二、扩容前的准备工作
就像做手术前要验血型，扩容也得先做全面检查：
-- 检查集群状态（技术栈：OceanBase SQL）
SELECT zone, svr_ip, svr_port, role, member_count
FROM __all_server
WHERE status = 'active';
-- 查看资源水位线
SELECT tenant_name, unit_config_id, max_cpu, max_memory/1024/1024/1024 as memory_gb
FROM __all_unit_config;
关键检查项：
- 确保所有节点
status为active - 记录当前的unit配置，特别是CPU和内存参数
- 准备新服务器需满足：
- 与现有节点同规格硬件
- 已安装相同版本的OceanBase软件包
- 网络延迟<1ms
三、详细扩容操作步骤
3.1 添加新节点
就像给自行车加链条，得先装好齿轮再上油：
# 在新节点上执行（技术栈：OceanBase命令行）
obadmin server add \
--ip=192.168.10.4 \
--port=2882 \
--zone=zone1 \
--cluster_id=123456
参数说明：
--zone必须与现有zone名称严格一致cluster_id可通过SHOW PARAMETERS LIKE 'cluster_id'获取
3.2 调整资源单元
这步类似给新房客分配卧室面积：
-- 创建新unit配置（示例增加50%资源）
CREATE RESOURCE UNIT new_unit_config
MAX_CPU 6,
MAX_MEMORY '32G',
MAX_DISK_SIZE '50G';
-- 分配给新节点
ALTER TENANT test_tenant
ADD UNIT = (unit_name 'unit4', unit_config 'new_unit_config', zone 'zone1');
3.3 数据自动均衡
OceanBase会自动开启数据迁移，可通过以下命令监控进度：
-- 查看迁移任务
SELECT * FROM __all_virtual_trans_stat
WHERE table_type IN ('DATA', 'INDEX');
-- 检查副本分布
SELECT table_name, partition_id, svr_ip
FROM __all_virtual_table_location
ORDER BY table_name;
四、扩容后的验证工作
扩容完不检查，就像装修完不验收——后患无穷：
- 基础功能测试：
-- 创建测试表验证写入能力
CREATE TABLE stress_test (
id BIGINT PRIMARY KEY,
payload VARCHAR(1024)
) PARTITION BY HASH(id) PARTITIONS 16;
-- 插入性能测试（应接近扩容前水平）
INSERT INTO stress_test
SELECT seq, RPAD('X', 1000, 'Y')
FROM (SELECT ROWNUM as seq FROM DUAL CONNECT BY ROWNUM <= 100000);
- 性能对比指标：
- 平均写入延迟差异应<15%
- 跨节点查询耗时波动<20%
五、那些年我们踩过的坑
5.1 时区不一致导致节点失联
某次扩容后突然出现节点离线，排查发现：
# 错误现象
$ obclient -h192.168.10.4 -P2881 -uroot
ERROR 4012 (HY000): Server is not available
# 根本原因
$ timedatectl | grep Timezone
Timezone: America/New_York (EDT, -0400)
解决方案：所有节点必须统一使用UTC时区
5.2 磁盘调度策略引发IO瓶颈
曾遇到新节点性能异常，最终发现：
# 检查调度器类型
$ cat /sys/block/sdb/queue/scheduler
[mq-deadline] kyber none
# 修正为与老节点一致
$ echo 'kyber' > /sys/block/sdb/queue/scheduler
六、扩容的进阶玩法
6.1 滚动扩容方案
对于7*24小时业务，可以采用：
- 逐个zone进行扩容
- 每次只下线1个节点
- 通过以下命令平滑迁移：
ALTER SYSTEM MIGRATE PARTITION
FROM '192.168.10.1:2882'
TO '192.168.10.4:2882'
PARTITION_ID_LIST('1101','1102');
6.2 混合部署优化
在资源紧张时，可以：
-- 将日志型tenant部署到新节点
CREATE TENANT log_tenant
RESOURCE_POOL_LIST = ('pool_log')
SET ob_tcp_invited_nodes='%';
-- 专门配置大磁盘unit
CREATE RESOURCE UNIT log_unit
MAX_DISK_SIZE '5T';
七、技术选型的思考
相比MySQL分库分表方案，OceanBase扩容具有：
优势：
- 自动数据再平衡，无需人工干预
- 应用无感知，连接串无需修改
- 支持在线操作，停机时间<30秒
劣势：
- 对网络稳定性要求极高
- 小集群(<3节点)扩容成本较高
八、总结 checklist
完成所有操作后，记得核对：
- [ ] 所有新节点
status=active - [ ] 各tenant资源配额已更新
- [ ] 数据副本分布均匀
- [ ] 性能测试结果达标
- [ ] 监控系统已纳入新节点
记住：扩容不是终点，而是新阶段的起点。建议在业务低峰期进行，并保留20%以上的资源余量应对突发流量。
评论