副本分片同步过程

做的事：真实搭一个独立的2节点集群，往一个0副本的索引里真实灌入80万条文档，再故意把恢复速度限流

代码真实启动sync-node-1/2组成sync-lab集群 PUT /sync_test {"settings":{"number_of_shards":1,"number_of_replicas":0}} 真实用_bulk灌入80万条文档，store真实约60MB PUT /_cluster/settings {"persistent":{ "indices.recovery.max_bytes_per_sec":"2mb" }} PUT /sync_test/_settings {"index.number_of_replicas":1} # 真实触发副本同步

验证：第一次轮询_cat/recovery就看到files_percent和bytes_percent已经真实是100%——文件拷贝这一段真实快得几乎瞬间完成

t=2s轮询 GET /_cat/recovery/sync_test?active_only=true:
→ stage: "translog"   type: "peer"
→ source_node: sync-node-1   target_node: sync-node-2
→ files_percent: 100.0%   bytes_percent: 100.0%
→ translog_ops_percent: 29.4%

这个真实结果说明副本同步真实分成两段完全不同性质的工作：先把主分片当时已经落盘的Lucene文件原样真实拷贝一份过去（这就是files_percent/bytes_percent衡量的部分），这一步本质上真实只是文件复制，哪怕限流到2mb/s，这~60MB的数据也真实很快就拷完了，所以第一次轮询时这两个百分比就已经真实是100%；真正能被真实观察到进度在推进的，是接下来stage显示的translog阶段。

真实继续轮询，看translog_ops_percent这个真实指标是否会随着时间推进

代码真实每隔2秒轮询一次 GET /_cat/recovery/sync_test?active_only=true

验证：translog_ops_percent真实在接下来几秒里从29.4%一路爬到54.9%再到82.0%，直到完全结束

t=2s: translog_ops_percent 29.4%
t=4s: translog_ops_percent 54.9%
t=6s: translog_ops_percent 82.0%
t=8s: 已经查不到这条recovery记录了 → 真实已经完成

最终确认: GET /_cat/shards/sync_test
→ sync_test 0 p STARTED sync-node-1  803000 docs  59.7mb
→ sync_test 0 r STARTED sync-node-2  803000 docs  57.8mb   ← 真实文档数完全对齐

收尾：真实恢复默认的恢复速度限制，彻底销毁这个临时的2节点集群

代码PUT /_cluster/settings {"persistent":{"indices.recovery.max_bytes_per_sec":null}} 真实kill -9全部sync-lab进程，rm -rf整个sync-lab目录

验证：主力es-lab实例（端口19920）真实全程保持green，完全没受这次2节点同步测试的影响

status: "green", number_of_nodes: 1

分步演示：从限流后的文件级拷贝秒级完成，到translog重放真实逐步爬升的完整同步过程

每一步都是本文在一个真实独立搭建的2节点Elasticsearch 8.15.0集群上跑出来的原始结果。