基于Elasticsearch Snapshot API实现集群Blue Green部署的技术问询

DevOps 小满

2026-5-21

Elasticsearch 集群蓝绿部署实战方案（基于Snapshot API）

通过全量快照初始化新集群，再同步快照后的增量数据，最终平滑切换流量，实现零停机的蓝绿部署。

给现有生产集群（蓝集群）创建全量快照，使用Snapshot API完成：
```
PUT /_snapshot/my_shared_repo/snapshot_prod_blue?wait_for_completion=true
```
注意：快照仓库my_shared_repo必须是蓝绿集群都能访问的共享存储（比如S3、HDFS或本地共享目录），提前配置好仓库权限。
启动全新的绿集群，确保集群配置（分片数、副本数、索引模板、Ingest管道等）和蓝集群完全一致。
在绿集群上从全量快照恢复数据：
```
POST /_snapshot/my_shared_repo/snapshot_prod_blue/_restore
```
恢复完成后，绿集群就拥有了快照时间点的完整数据集。

这是关键环节，要确保快照创建后蓝集群的所有写入都同步到绿集群：

首先获取快照完成的精确时间戳：调用GET /_snapshot/my_shared_repo/snapshot_prod_blue，从返回结果的end_time字段拿到时间戳，这个是增量同步的起始点。
选择合适的增量同步方式：
- 业务层双写：如果你的写入请求都经过统一的业务服务，可以临时修改业务逻辑，让所有写入同时发送到蓝集群和绿集群。这种方式实时性最好，但需要业务层支持双写重试、失败降级等逻辑，适合业务改造成本低的场景。
- ES滚动查询同步：如果业务层不好修改，可以通过Elasticsearch的滚动查询拉取增量数据：
  1. 用scroll API查询蓝集群中@timestamp（或你业务的时间字段）大于快照时间戳的文档：
```
POST /_search?scroll=5m
{
  "query": {
    "range": {
      "@timestamp": {
        "gt": "2024-05-20T10:00:00.000Z"
      }
    }
  },
  "size": 1000
}
```
  2. 拿到查询结果后，用_bulk API批量写入绿集群，同时要处理删除操作（可以通过查询_deleted字段或利用版本号来同步删除动作）。
  3. 定期执行这个同步逻辑，直到绿集群的增量数据完全追上蓝集群（连续几次校验数据一致即可）。
数据校验：同步过程中要定期做一致性校验，比如对比蓝绿集群的索引文档数、抽样对比文档内容，或者用_count API统计时间范围的文档数量，确保同步准确。

当增量数据同步完全追上蓝集群（比如连续3次校验数据一致，且延迟在可接受范围内），就可以开始切换流量：修改负载均衡配置、业务服务的ES连接地址，将所有请求导向绿集群。
切换后观察绿集群的运行状态：监控CPU、内存、写入/查询延迟、分片健康状态等，确认稳定运行一段时间（比如1小时）。
确认绿集群正常后，停止增量同步逻辑，后续可以根据需求保留蓝集群作为备份，或者直接销毁。

内容的提问来源于stack exchange，提问作者JDBet