扩容窗口里，最容易确认的一件事是新节点是否出现在集群列表中。相比之下，数据重新分布时，应用请求有没有失败、延迟抖动持续了多久、什么时候才算扩容完成，往往更难回答。
多副本集群在线增加一个节点时，怎样把“业务无感”变成一组可验证的条件？扩容后系统会自动进行数据重分布以实现负载均衡。下面围绕这段重分布过程，设计一场能观察、能判断、能复盘的扩容演练。
一、先把“无中断”定义清楚
“零中断”不能只用“集群没停机”来定义。对业务来说，更实际的判断是：持续请求没有不可恢复的失败，短暂延迟变化没有突破服务 SLO，扩容前后的数据校验一致。
因此，演练开始前先选定一条真实业务路径作为探针。例如每秒读取一台设备最近一条测量值，并向测试设备写入一条带唯一 ID 的记录。探针应经过与线上相同的连接池、超时和重试逻辑；否则只测数据库端口通不通，不能代表应用真的可用。
扩容期间至少记录四类信号：
| 信号 | 为什么要看 |
|---|---|
| 请求成功率与错误类型 | 判断是否有超时、连接断开或写入失败 |
| P95/P99 延迟 | 发现平均值掩盖的尾部抖动 |
| 新旧节点的 CPU、磁盘 I/O、网络 | 判断重分布是否与业务争抢资源 |
| 节点状态与集群告警 | 确认节点加入后是否稳定，是否有副本或网络异常 |
演练判据可以写成：扩容期间探针请求持续成功，P95/P99 不超过预设 SLO；若出现短时重试，业务没有重复副作用；扩容后读回写入记录并核对数据。假设业务 SLO 是 P95 小于 200 ms，就以 200 ms 作为硬边界，不要等看到图表后再解释结果。
二、把场景固定下来，估算观察窗口
为了让演练可复述，先固定一个参考场景：现有 3 个数据节点，增加 1 个节点；预计需要重新分布的数据约 1 TB；节点间为 10 GbE 网络；业务持续读写。
| 参数 | 参考场景 |
|---|---|
| 扩容前节点数 | 3 |
| 新增节点数 | 1 |
| 预计重分布数据量 | 约 1 TB |
| 有效迁移带宽估算 | 60–140 MB/s |
| 预计重分布窗口 | 约 2–5 小时 |
| 规划中的 P95 波动 | 暂按基线的 10%–30% 预留观察空间 |
窗口估算用的是有效迁移带宽，而不是网卡标称速度：
1 TB ÷ 140 MB/s ≈ 2 小时
1 TB ÷ 60 MB/s ≈ 4.6 小时
因此，演练排期可以按 2–5 小时预留重分布观察时间。10 GbE 不代表数据库能以 10 Gb/s 搬数据；磁盘读写、CPU、网络竞争、业务流量和副本调度都会压低实际带宽。P95 上升 10%–30% 是本场景预留的观察空间，不是 KaiwuDB 的性能承诺。判断仍以探针数据和业务 SLO 为准。
固定这些条件还有一个好处：若窗口远超估算，排查可以集中在“实际迁移量是否高于 1 TB、有效带宽是否低于 60 MB/s、是否存在资源争用”，而不是笼统地说“扩容很慢”。
三、扩容前只做一件关键事：建立对照基线
扩容前先确认几个条件：待扩容节点尚未安装 KaiwuDB，目标集群处于运行状态，当前节点数没有达到许可证上限。使用安装程序时，执行节点还要能通过 SSH 登录新节点，并拥有安装目录写权限。安全部署时，新节点的安全模式必须与目标集群一致，并准备好所需证书。
准入条件确认后，还要有扩容前的对照数据。建议在操作前连续采集 15 分钟：
- 探针请求成功率、P95/P99 延迟及错误码；
- 各节点 CPU、磁盘 I/O、网络吞吐和可用空间；
- 当前集群节点状态与告警。
把这些指标作为基线，扩容期间每分钟采样，操作完成后继续观察 15 分钟，区分短暂波动与持续退化。若扩容前集群已经有节点异常、磁盘空间紧张或业务延迟接近 SLO 上限，先恢复健康或另选变更窗口。
四、加入节点：入口可以不同，检查点不能少
安装程序交互方式和命令行方式都可以加入节点。对这场演练，入口不是重点：无论使用 GUI 还是 CLI，都要确认选择的是多副本集群，并将新节点的安全模式、服务端口、数据目录和集群地址配置正确。
命令行场景中，通过启动新节点并指定数据目录、监听地址、HTTP 地址和已有节点列表加入集群。下面保留参数结构作为示意，证书和地址需要替换为实际值；TLS、TLCP 或非安全模式必须与现有集群匹配：
<kwbase_path>/kwbase start \
--certs-dir=<cert_path> \
--store=<data_dir> \
--brpc-addr=:27257 \
--listen-addr=<new_node_ip>:<kaiwudb_port> \
--http-addr=<new_node_ip>:<rest_port> \
--join=<node_address_list> \
--background
安装完成后，先用 kw-status 检查节点是否加入；也可按安全模式使用 kwbase node status 查看节点状态。常见默认端口是 KaiwuDB 服务端口 26257、Admin UI 端口 8080、数据传输端口 27257，生产环境应以实际配置为准。
节点状态正常，只能说明新节点已加入并可被集群识别，不能证明数据重分布已经结束，也不能证明业务侧没有失败。从这一刻开始，演练的重心应转向监控和业务探针。
五、重分布期间，关注业务与资源的关联
多副本集群扩容后会自动进行数据重分布。迁移持续数小时并不等于业务中断，关键是线上请求受到什么影响，以及影响是否仍在 SLO 之内。
观察时把指标放在同一条时间线上：
时间 扩容操作/节点状态 重分布与资源 业务探针
T-15 min 集群稳定 资源基线 成功率、P95/P99 基线
T0 开始加入新节点 连接/启动 持续请求
T+... 新节点正常 观察磁盘、网络 观察错误与尾延迟
T+2~5 h 等待负载趋稳 节点负载逐步均衡 验证 SLO 与数据
如果 P95 上升同时伴随磁盘 I/O 或网络接近饱和，优先判断是否发生资源争用；如果探针出现连接错误但重试后成功，还要检查应用是否可能重复提交写入；如果新节点反复掉线，则先处理节点健康问题，不要继续叠加其他变更。
重分布期间应避免频繁执行 ALTER，以免延长数据重分布时间。集群设置中也提供了关闭自动重平衡考虑项的参数：
SET CLUSTER SETTING kv.allocator.ts_consider_rebalance.enabled = false;
这不是常规扩容步骤。除非有明确运维目的、理解设置影响并准备好恢复方案，否则应保持自动重分布。演练要观察系统如何完成均衡，不要为了让监控曲线好看而先关闭它。
六、什么时候可以说扩容完成
节点已加入只是过程事件。满足以下条件后，再结束变更窗口：
- 新节点在
kw-status或状态检查中持续正常，没有反复加入或退出。 - 业务探针成功率符合预设目标，P95/P99 回到基线附近或处于业务 SLO 范围内。
- 连接错误、超时和重试没有持续增长；写入重试没有造成重复业务记录。
- 读取扩容前后的代表性数据，核对记录数、时间范围和关键聚合值。
- 节点资源和集群告警趋于稳定，重分布影响不再持续扩大。
若扩容目标是替换故障节点，旧节点退役要单独检查。双副本集群可以在新节点加入后进行副本平衡，再通过节点退役命令移除故障节点，并等待副本迁移完成。不要因为新节点出现在状态列表中就立刻退役旧节点；先确认副本补足和集群健康，再按目标版本的退役流程操作。
七、如果波动超出预期，先暂停而不是继续加操作
如果探针持续失败、延迟突破 SLO、磁盘或网络接近耗尽，先暂停后续变更，保留节点状态、业务指标和日志时间线。不要同时关闭自动重平衡、频繁修改表结构或继续加入更多节点，否则变量叠加后很难定位问题。
对于超过 5 小时仍未趋稳的参考场景，可以先核对三个量：实际待迁移数据量、有效迁移带宽、扩容期间的业务资源占用。若迁移量实际是 2 TB，按相同有效带宽估算窗口可能扩大到约 4–10 小时；若有效带宽只有 30 MB/s，单 TB 数据的传输下限就接近 9 小时，还未计入调度与业务竞争。此类估算用于决定是否继续等待或安排维护窗口，不能替代对集群状态和业务指标的判断。
结语：连续性要由业务探针证明
在线扩容不是新节点启动成功就结束。先记录业务基线，再加入节点，观察自动重分布对资源和请求的影响，最后确认数据完整、业务 SLO 恢复。
因此，“零中断”不能靠一条命令保证。持续请求成功率、尾延迟、错误与重试记录，以及扩容前后的数据校验，才是判断业务是否无感的依据。
评论(0)