4.2 扩缩容与修复

4.2 扩缩容与修复

本节摘要：加节点走 bootstrap/streaming；下线用 decommission；一致性靠 Incremental Repair（4.x）与 Reaper 调度。SOURCE 4.2：盲目 repair 全集群与忽略 repair 同样危险。

你能学到什么

阅读完本节，你应当能够：

1. 执行 nodetool bootstrap / decommission 流程
2. 解释 streaming 与 compaction 争抢磁盘的症状
3. 配置 Incremental Repair 与 gc_grace_seconds 关系
4. 对比 HBase Region move 与 Mongo resharding

一、问题与直觉

促销前加 6 台机器——若直接改 token 或 kill 旧节点，会出现 double data 或丢 QUORUM。Cassandra 扩缩容是有状态操作：新节点从 ring 邻居拉 SSTable（streaming），旧节点 decommission 把 vnode 迁出。MongoDB 4.x+ resharding 后台 chunk 迁移；HBase balancer 移动 Region——都有 I/O 风暴窗口，需限速与监控。

二、核心原理

加节点：

1. 配好 yaml/rackdc，启动 Cassandra
2. 自动 bootstrap（或 nodetool bootstrap 旧版）
3. 观察 nodetool netstats streaming 进度
4. 完成后 nodetool cleanup 旧节点冗余副本（NTS 变更后）

缩节点：nodetool decommission——数据流出，忌直接 stop daemon。

Repair 类型：

Anti-Entropy 用 Merkle Tree 比对 token 段；不一致则 streaming 差异 SSTable。

Reaper：开源 repair 调度器，cron 分 DC、分 keyspace，避免人工遗忘。DataStax OpsCenter 提供 GUI 同类能力。

gc_grace：repair 必须在 tombstone 可 GC 前覆盖所有副本，否则删除「复活」。

三、工程实践要点

streaming 限速：stream_throughput_outbound_megabits_per_sec 防打满带宽影响生产 CL。

replace dead node：nodetool removenode + 同 token 新机器 replace_address——比 decommission 快但风险高。

监控：Pending Compactions、Repair sessions、Dropped Mutations 三联看。

⚠️ 常见坑：新节点 bootstrap 未完成就接流量——局部 CL 不足。

💡 关键直觉：repair 不是可选保养，是异步复制模型的闭合环。

要点串联

• bootstrap/decommission 是有序扩缩容入口
• Incremental repair 替代全量马拉松
• Merkle + streaming 是反熵实现
• Reaper 把 repair 变成 cron 纪律
• gc_grace 与 tombstone 绑定 repair 窗口

下一节合并快照备份与 RBAC/TLS 安全。

演练：扩节点全流程

# 第1步：新节点配好 yaml/rackdc，确保 cluster_name、seeds 一致
# 第2步：启动新节点，观察进入 bootstrap
nodetool bootstrap
# 第3步：监控 streaming 进度（等待迁入数据完成）
nodetool netstats
# 第4步：状态变为 UN 后，检查数据是否均匀
nodetool status
​

# 扩容前先限速，避免 streaming 打满带宽影响生产
stream_throughput_outbound_megabits_per_sec: 50
​

# 扩容后旧节点可能持有本不该再负责的副本，执行清理
nodetool cleanup
​

扩节点不是「加台机器」这么简单：streaming 期间写负载与 Compaction 并发，建议在低峰窗口执行；cleanup 只对旧节点执行，新节点不需要。若中途失败，清理 data 目录后重来，远比强行改 token 安全。

演练：替换坏节点

# 方案 A（推荐）：原地替换，保留原 token
# 1. 在替代机上配置与原节点相同的 token 与 listen_address
# 2. 启动时指定 replace_address 指向坏节点 IP
replace_address: 10.0.1.10

# 方案 B：移出环再补新节点
nodetool removenode <bad_node_id>   # 触发数据迁出
nodetool status                     # 确认环恢复正常后加入新节点
​

# 替换完成后立即做一轮增量 repair 收敛差异
nodetool repair -inc
​

替换坏节点的风险点：原节点数据可能部分丢失，替换完成后必须 repair 补齐；操作前确认原节点已彻底下线，否则两个节点抢同一 token 会造成路由冲突。方案 A 快但有风险，方案 B 慢但干净，二选一取决于坏节点能否安全离线。

修复调度与告警

# Reaper 配置示意：每周六凌晨对全部 keyspace 做增量 repair
repair:
  schedule: "0 2 * * 6"
  intensity: 0.8
  incremental: true
  datacenters: [dc-east, dc-west]
​

# 关键告警指标：三者联动看
nodetool compactionstats   # Pending Compactions 持续 > 0
nodetool tpstats           # Dropped Mutations > 0
nodetool netstats          # Streaming 是否异常卡住
​

告警设计原则：Pending Compactions 高不一定是故障，但伴随 Dropped Mutations 上升就是写路径被拖垮的信号，应优先查磁盘 I/O 与 GC；Streaming 卡住则查带宽与防火墙。三者同屏，才能区分「正常阵痛」与「真实故障」。

演练：decommission 完整流程

# 第1步：确认节点状态正常，能被安全移出
nodetool status

# 第2步：执行 decommission（数据迁出 + 退出环）
nodetool decommission
# 观察输出：节点持有的 token range 正被重新分配

# 第3步：监控迁移进度
nodetool netstats
# 完成后该节点从环中消失，stop daemon 收尾
​

# 若 decommission 中途失败（网络抖动），重试前先检查：
nodetool status          # 环是否完整、是否有 DN 节点
# 长期无法 decommission 时，可强制 removenode 但需谨慎
​

decommission 与「直接停进程」的区别：前者主动把数据交给邻居，后者留下数据缺口，后续所有读都会撞上缺失副本，触发 Read Repair 风暴。缩容纪律第一条：永远走 decommission，而不是 kill -9。HBase 对应的是 graceful_stop 后 Region 迁移，Mongo 则靠 rs.remove()——机制不同，原则一致：数据先走，人再退。

常见修复失败场景对照

# 分片 repair：把环切成 N 段逐段修复，避免单次马拉松
nodetool repair -inc -st $(start_token) -et $(end_token) shop
​

修复的本质是「有界、可中断、可恢复」：任何 repair 作业都要能在中途取消而不留下坏状态，这正是增量 repair 相对全量 repair 的优势——它记录已完成的 token 段，续跑只补未完成部分。