Elasticsearch 跨集群副本同步方案详细设计

原创已于 2025-08-17 07:45:10 修改 · 801 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#elasticsearch #跨集群副本 #同步方案 #学习

于 2025-08-17 02:49:24 首次发布

搜索引擎专栏收录该内容

55 篇文章

订阅专栏

在多数据中心、灾备容灾或读写分离的架构中，Elasticsearch 跨集群副本同步（Cross-Cluster Replica Synchronization） 是实现高可用、异地容灾和负载分担的关键能力。

本文将为你提供一套 完整、生产级的 Elasticsearch 跨集群副本同步方案详细设计，涵盖技术选型、架构设计、数据一致性、故障恢复、监控告警等核心环节。

一、目标与核心需求

目标	说明
✅ 数据异地容灾	主集群故障时，备集群可接管服务
✅ 读写分离	写入主集群，查询可路由到备集群
✅ 近实时同步	延迟控制在秒级（可配置）
✅ 自动故障转移	支持手动或自动切换主备角色
✅ 可监控可审计	同步状态、延迟、失败记录可查
✅ 安全可靠	支持加密、权限控制、断点续传

二、技术选型对比

Elasticsearch 提供两种跨集群复制方案：

方案	说明	适用场景
CCR（Cross-Cluster Replication）	基于 follower-follower 模型，索引级复制	✅ 生产推荐，支持异步复制
CCS + Logstash	通过 Logstash 消费主集群数据写入备集群	灵活但复杂，易丢数据
Kafka + 自研同步服务	主集群导出变更 → Kafka → 消费写入备集群	高定制化，需维护
Snapshot & Restore	定时快照恢复到备集群	仅用于灾备，延迟高

✅ 推荐方案：CCR（Cross-Cluster Replication），原生支持、低延迟、高可靠性。

三、CCR 原理简介

CCR 使用 follower-follower 架构：

Leader Cluster（主）：接受写入，数据源；
Follower Cluster（从）：拉取 leader 索引的 translog，异步应用变更；
Auto-follow：支持自动同步新索引（如 rollover 后的新索引）。

Leader Cluster
   ↓ pull replication
Follower Cluster

数据流是 从 follower 主动拉取，而非 leader 推送。

四、系统架构设计

+---------------------+      +-----------------------+
|  Leader Cluster       |<---->|  Follower Cluster     |
|  (Primary, 写入)       |      |  (DR, 读/灾备)         |
|                       |      |                       |
|  Index: logs-000001   |      |  Auto-follow: logs-*   |
|  ILM + Rollover       |      |  Read-only 或可写切换  |
+----------+------------+      +-----------+-----------+
           |                               |
           |  Cross-Cluster Search         |
           +------------+------------------+
                        |
                        v
               +------------------+
               |  Client / App    |
               |  - 写入 leader   |
               |  - 查询可选 follower |
               +------------------+

部署模式

模式	说明
同城双活	两集群在不同机房，网络延迟 < 5ms
异地灾备	主在华东，备在华北，延迟较高（50~100ms）
多区域读	主写，多个区域部署 follower 用于本地读

五、详细实施步骤

1. 配置跨集群连接（Remote Clusters）

在 Follower Cluster 上配置连接到 Leader：

PUT /_cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "leader-cluster": {
          "seeds": ["leader-node1:9300", "leader-node2:9300"]
        }
      }
    }
  }
}

使用 transport port（9300），非 HTTP。

验证连接：

GET /_remote/info

2. 创建 Follower Index（手动同步）

PUT /logs-000001-follower
{
  "settings": {
    "index.replication.type": "ASYNC",
    "index.shard.checkpoint_interval": "60s"
  },
  "mappings": {
    "properties": { ... }
  }
}

启动复制：

POST /_ccr/follow?wait_for_active_shards=1
{
  "leader_index": "logs-000001",
  "remote_cluster": "leader-cluster"
}

3. 配置 Auto-Follow（自动同步 rollover 索引）

PUT /_ccr/auto_follow/leader-logs-pattern
{
  "remote_cluster": "leader-cluster",
  "leader_index_patterns": [
    "logs-*"
  ],
  "follow_index_pattern": "{{leader_index}}-follower"
}

当 logs-000002 被创建时，自动在 follower 集群创建 logs-000002-follower 并开始同步。

六、数据一致性与延迟控制

1. 同步机制

Follower 定期从 leader 拉取 translog（事务日志）；
应用变更到本地索引；
支持 checkpoint 机制，记录已同步位置。

2. 延迟监控

GET /logs-000001-follower/_ccr/stats

返回关键指标：

"following_index_stats": {
  "index": "logs-000001-follower",
  "time_since_last_read_millis": 120,
  "write_checkpoint": {
    "leader_global_checkpoint": 15000,
    "follower_global_checkpoint": 14980
  }
}

global_checkpoint 差值越小，延迟越低。

3. 一致性级别（可配置）

参数	说明
`index.replication.type: ASYNC`	默认，高性能
`index.replication.type: SYNC`	同步复制，写入 leader 前等待 follower 确认（不推荐，影响性能）

推荐使用 ASYNC，通过监控控制风险。

七、故障恢复与主备切换

1. 手动切换（推荐）

当 leader 集群故障时：

Step 1：暂停 follower 同步

POST /logs-000001-follower/_ccr/pause_follow

Step 2：提升为可写索引

# 删除 CCR 设置
PUT /logs-000001-follower/_settings
{
  "index.replication.type": null
}

# 可选：重命名
POST /logs-000001-follower/_clone/logs-000001

Step 3：应用切换写入地址

2. 自动切换（需外部系统）

使用 健康检查 + 切换脚本 实现自动 failover：

if ! curl -s http://leader-cluster:9200/_cluster/health | grep -q "green\|yellow"; then
  trigger_failover_to_follower
fi

⚠️ 自动切换需谨慎，避免脑裂。

八、安全与权限控制

1. TLS 加密

启用 transport.ssl 和 http.ssl；
跨集群通信使用证书加密。

2. RBAC 权限

在 leader 集群创建专用用户：

POST /_security/user/follower_reader
{
  "password": "xxxx",
  "roles": ["cross_cluster_replication"],
  "full_name": "Follower Cluster Reader"
}

在 follower 集群配置 API Key 或用户名密码。

九、监控与告警

1. 关键监控指标

指标	采集方式	告警阈值
`time_since_last_read_millis` > 5000	`_ccr/stats`	延迟过高
`leader_global_checkpoint - follower_global_checkpoint > 1000`	差值	数据滞后
`follow_request_rejection_count` > 0	CCR stats	同步失败
follower 集群状态 ≠ green	`_cluster/health`	集群异常

2. 告警规则示例（Prometheus）

- name: "CCR Replication Lag High"
  expr: |
    elasticsearch_ccr_time_since_last_read_ms{job="es-follower"} > 5000
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "CCR 同步延迟过高"

十、性能优化建议

优化点	建议
网络	使用专线或内网，降低延迟
批量拉取	调整 `max_read_request_operation_count`
checkpoint 间隔	`index.shard.checkpoint_interval: 30s`
分片数匹配	follower 索引分片数可不同（但 leader 分片不能增减）
避免大事务	减少 bulk 大小，避免阻塞

十一、限制与注意事项

限制	说明	规避方案
不能修改 leader 索引的主分片数	否则 follower 无法同步	需 reindex
不支持 follower → leader 写入	CCR 是单向的	手动切换角色
auto-follow 不支持 nested rollover	如 `logs-write` → `logs-000001`	需监控并手动配置
网络中断后自动恢复	支持断点续传	无需人工干预

十二、最佳实践 checklist ✅

项目	建议
使用 CCR 而非 Logstash	更可靠
启用 auto-follow	支持 rollover
监控同步延迟	实时感知
定期演练 failover	验证灾备能力
权限最小化	仅授予必要权限
多集群命名规范	`logs-000001-follower` 易识别

十三、扩展建议

场景	建议方案
双向复制	使用两个 CCR 任务，实现双活（需防循环写入）
多级复制	leader → follower1 → follower2（边缘节点）
向量同步	CCR 支持 `dense_vector` 字段
与 ILM 联动	follower 集群可独立设置 ILM 策略