解读

在国内生产环境，CouchDB 集群扩容往往采用“先加节点、再移分片”的在线方案。move-shard 只是把分片文件从源节点拷贝到目标节点，并启动内部连续复制任务；真正的“安全”时刻是内部复制进度达到 100% 且校验和一致，否则提前摘掉源副本会造成数据丢失或读写 500。因此面试官想确认两点：

1. 你是否知道 move-shard 背后其实是 _replicator 文档触发的连续复制；
2. 你是否能用官方/社区认可的方式实时量化进度，而不是靠“感觉”或“等一会”。

知识点

1. 内部复制任务命名规则：move-shard 会在 _replicator 数据库里写入源节点→目标节点的文档，doc._id 形如“shards/80000000-ffffffff/{db}.{147196….timestamp}”。
2. 进度指标字段：连续复制文档的 _replicator_state=“triggered” 时，CouchDB 每 5 秒回写一次状态，关键字段为
   • checkpointed_source_seq：已经复制到的更新序列
   • source_seq：源节点当前最新序列
   • missing_revs_found / docs_read / docs_written：已传输的修订计数
3. 进度百分比公式：
   progress = (checkpointed_source_seq / source_seq) × 100%
   当 source_seq 与 checkpointed_source_seq 相等且 doc.state 变为 “completed” 时，可认为 100%。
4. 监控入口：
   • /_active_tasks 接口返回所有正在运行的复制任务，包含同一套指标，无需鉴权即可查看。
   • /_scheduler/jobs（CouchDB 2.3+）提供 JSON 化、带时间戳的进度，适合脚本轮询。
5. 国内运维习惯：
   • 用 Python + requests 每 10 秒轮询 /_active_tasks，计算进度并落库到 Prometheus Pushgateway，Grafana 大盘实时展示；
   • 当进度≥99.9% 且持续 3 个周期无变化，再调用 /_node/_local/_system 确认磁盘同步，最后执行 “cleanup-shard” 摘掉旧副本。

答案

1. 在管理节点执行
   curl -s $SRC_NODE/_active_tasks | jq '.[] | select(.type=="replication" and .target=="http://$TGT_NODE:5984/$DB")'
   提取字段 checkpointed_source_seq 与 source_seq，计算百分比。
2. 若集群版本 ≥2.3，推荐
   curl -s $SRC_NODE/_scheduler/jobs | jq '.jobs[] | select(.database=="$DB" and .target_node=="$TGT_NODE") | .progress’
   当返回 100 且状态为 “completed” 时，内部复制完成。
3. 为了自动化，可写 Bash 循环：
   until (( $(curl -s$SRC_NODE/_active_tasks | jq '.[0].checkpointed_source_seq') == $(curl -s$SRC_NODE/_active_tasks | jq '.[0].source_seq') )); do sleep 10; done
   循环退出即代表 100%，再执行下一步摘除操作。

拓展思考

• 如果源节点在复制过程中宕机，_active_tasks 会消失，此时应到 目标节点 的 _scheduler/jobs 查看是否已自动重连；若重连后 source_seq 重置，需要重新计算进度，避免误判。
• 对于 跨机房高延迟 场景，可调整 worker_processes=8、http_connections=20 以加速复制，同时监控 docs_pending 指标，防止内存堆积。
• 国内部分金融客户要求“零数据差”，可在进度 100% 后做一次 /_revs_diff 抽样校验，确认目标节点无缺失修订，再摘掉旧副本，满足审计合规。