📚 课程目录第4章 Elastic灾备策略设计

4. Elastic灾备策略设计

灾备策略的本质，是在RTO（恢复时间目标）与RPO（恢复点目标）两个约束下，选择一套可落地的数据复制方式、集群拓扑与切换机制。Elasticsearch 的灾备能力并非单一开关，而是由快照仓库、跨集群复制（CCR）、跨集群搜索（CCS）、副本分片、负载均衡与流量调度等多个机制组合而成。理解这些机制的差异，才能在设计时做出正确的取舍。

五种典型策略的机制与定位

冷备依赖快照与恢复（Snapshot & Restore）。通过注册共享仓库（如 S3、HDFS、NFS），按周期对索引执行快照，故障时在新集群中恢复。它的 RPO 等于快照间隔，通常为小时级；RTO 取决于数据量与恢复并行度，往往是小时到天级。冷备成本最低，适合日志归档、合规留存等可容忍较长中断的场景。

温备在冷备基础上缩短了恢复路径：备用集群常驻但规模较小，快照持续同步，故障时先恢复核心索引对外提供有限查询，再逐步补齐。它的 RPO 仍在分钟到小时级，RTO 可压缩到分钟级，成本中等。

热备使用 CCR 将主集群的索引持续复制到备用集群，备用集群保持可读、可随时提升为主。CCR 基于分片级拉取，复制延迟通常在秒级，因此 RPO 可达秒级；配合自动或半自动切换，RTO 可控制在分钟以内。热备适合订单、支付等对数据丢失敏感的业务。

双活指两个集群同时承载读写流量，通过 CCR 双向复制或应用层双写保持数据一致。它需要解决写冲突、主键冲突与回环复制问题，通常要求业务具备按租户或按 ID 段路由的能力。双活的 RTO 接近零，RPO 接近零，但复杂度与成本显著上升。

多活是双活在地域维度上的扩展，三个及以上集群同时服务，配合全局负载均衡与就近接入。它提供最高的可用性，但一致性模型、冲突解决与运维复杂度也最高，一般只用于核心链路。

基于 RTO/RPO 的选择方法

选择策略时，建议先量化业务指标，再反向匹配机制。可以按以下顺序推进：

确定 RPO 上限。若业务允许丢失 1 小时数据，快照间隔设为 30 分钟即可满足；若只允许丢失数秒，则必须使用 CCR 或双写。
确定 RTO 上限。若允许 4 小时中断，冷备恢复即可；若要求 5 分钟内恢复，备用集群必须常驻并预热。
核对数据规模与恢复速率。快照恢复速率受分片数、节点数与仓库带宽影响。例如 2TB 数据、20 个节点、每节点恢复吞吐约 80MB/s，理论恢复时间约为 2000GB ÷ (20×80MB/s) ≈ 1250 秒，约 21 分钟，实际还需叠加分片分配与段合并开销。
验证切换路径。热备与双活必须实际演练提升（promote）与流量切换，否则 RTO 只是纸面数字。

RPO 与 RTO 是业务指标，不是技术指标。设计时应先与业务方确认可接受范围，再选择机制，而不是先选技术再倒推指标。

成本与复杂度的权衡

成本主要由三部分构成：计算与存储资源（备用集群规模）、跨域带宽（复制流量）、运维人力（演练、监控、故障处理）。冷备几乎不占用常驻资源，成本最低；热备需要一套与主集群规模相当的备用集群，成本约为冷备的数倍；双活与多活则成倍增长。

复杂度方面，冷备只需管理快照生命周期；热备需要处理 CCR 的复制延迟、索引模板同步与自动跟随（auto-follow）规则；双活必须解决写冲突。以 CCR 双向复制为例，若两个集群同时写入同一文档，后写入者覆盖先写入者，且可能产生复制回环。常见做法是让每个集群只写自己负责的租户段，或引入外部版本号与冲突解决策略。

策略	典型 RPO	典型 RTO	核心机制	适用场景
冷备	小时级	小时~天级	快照 + 恢复	日志归档、合规留存
温备	分钟级	分钟级	小集群 + 快照同步	内部系统、非核心查询
热备	秒级	分钟级	CCR 单向复制	订单、支付等核心业务
双活	≈0	≈0	CCR 双向 / 双写	跨机房核心链路
多活	≈0	≈0	多集群 + 全局调度	多地容灾、就近接入

落地示例：热备集群的 CCR 配置

以下示例展示在备用集群上建立 CCR 跟随关系的关键步骤。假设主集群为 leader-cluster，备用集群为 follower-cluster，需要复制 orders-* 索引。

# 1. 在主集群创建用于复制的 API Key（需 manage_ccr 权限）
POST /_security/api_key
{
  "name": "ccr-key",
  "role_descriptors": {
    "ccr-role": {
      "cluster": ["manage_ccr", "read_ccr"],
      "indices": [{"names": ["orders-*"], "privileges": ["read", "monitor"]}]
    }
  }
}

# 2. 在备用集群配置远程集群连接
PUT /_cluster/settings
{
  "persistent": {
    "cluster.remote.leader-cluster.seeds": ["leader-host:9300"],
    "cluster.remote.leader-cluster.transport.ping_schedule": "60s"
  }
}

# 3. 创建自动跟随规则，自动复制匹配的索引
PUT /_ccr/auto_follow/orders-follow
{
  "remote_cluster": "leader-cluster",
  "leader_index_patterns": ["orders-*"],
  "follow_index_pattern": "{{leader_index}}",
  "max_read_request_operation_count": 5120,
  "max_outstanding_read_requests": 12
}

# 4. 查看复制状态，重点关注 lag 与 shard 状态
GET /orders-2024/_ccr/stats
GET /_ccr/auto_follow/orders-follow

配置完成后，应重点观察 _ccr/stats 中的 leader_global_checkpoint 与 follower_global_checkpoint 差值，差值越大说明复制延迟越高。若延迟持续增长，需检查跨域带宽、max_outstanding_read_requests 是否过小，以及主集群写入压力是否超过复制能力。

CCR 复制的是索引数据，不包含集群设置、ILM 策略、索引模板与安全配置。这些需要在备用集群单独维护，否则切换后可能出现索引生命周期或权限异常。

策略组合与演进建议

实际生产环境很少只使用单一策略。常见组合是：核心交易索引采用热备或双活，日志与行为数据采用冷备，报表类索引采用温备。这样既保证核心链路的 RPO/RTO，又避免为全量数据支付高额成本。

演进路径建议从冷备起步，先建立快照仓库与恢复演练机制；当业务对中断敏感时，升级为温备或热备；只有在跨机房高可用成为硬性要求、且团队具备多集群运维能力时，才考虑双活与多活。每一步升级都应伴随一次真实的切换演练，用实测 RTO 与 RPO 验证设计是否达标，而不是停留在架构图上。