2. Elastic架构与故障域分析

要谈Elastic的灾备恢复，第一步不是急着配快照仓库，而是先把集群的“骨架”和“薄弱点”看清楚。Elasticsearch是一个分布式系统，它把数据切成分片、把分片分散到节点、再用主节点统一管理元数据。理解这套结构，才能判断一次故障到底影响多大范围——是丢一个副本、挂一台机器，还是整个集群不可用。

集群、节点与角色分工

集群（cluster）是逻辑上的最大单位，由若干节点（node）组成，通过相同的 cluster.name 相互发现并协同工作。节点按职责可分为几类角色，实际生产中常通过 node.roles 显式指定：

• 主节点（master）：负责集群状态管理，如索引创建、分片分配、节点上下线决策。它不存储业务数据，但掌握“谁在哪里”的元数据。主节点通过选举产生，只有获得多数票的候选者才能成为 active master。
• 数据节点（data）：真正存储分片、执行读写和聚合的节点。数据量越大，对CPU、内存、磁盘IO的要求越高。
• 协调节点（coordinating）：接收客户端请求，把请求分发到相关分片所在节点，再汇总结果返回。每个节点默认都能充当协调角色，但大集群常设专用协调节点，避免数据节点被请求转发压垮。
• 摄取节点（ingest）：在写入前执行预处理管道（pipeline），如字段解析、富化。它可与数据节点合并，也可独立部署。

角色分离的核心目的是隔离故障域：主节点被大量写入拖垮，会导致集群无法响应元数据变更；协调节点过载，则客户端请求超时。因此生产环境通常至少配置3个专用主节点，数据节点与协调节点分开。

分片与副本：数据的高可用单元

索引在物理上被拆成若干主分片（primary shard），每个主分片可以有零到多个副本分片（replica shard）。主分片数量在索引创建时确定，之后不能直接修改（除非reindex或shrink/split）；副本数可以动态调整。

分片分配遵循两条硬规则：同一分片的主副本不能落在同一节点；集群状态为yellow时说明有副本未分配，red时说明有主分片未分配。例如一个索引设3个主分片、1个副本，共6个分片实例，至少需要2个数据节点才能全部变为green。若只有1个数据节点，副本无法分配，集群长期yellow——此时能读写，但没有冗余，一旦该节点故障就会丢数据。

故障域划分：从硬件到人为

故障域（failure domain）指一个故障能同时影响的最大范围。灾备设计的本质，就是让主副本跨越故障域分布。Elasticsearch常见的故障域可归为四层：

• 硬件故障：单块磁盘损坏、单台服务器宕机、单台交换机断电。影响范围是单节点或单机架。
• 网络故障：节点间心跳丢失、跨机房专线抖动、DNS解析异常。可能造成脑裂（split-brain）或主节点重新选举。
• 软件故障：JVM OOM、段合并风暴、版本升级不兼容、映射爆炸导致集群状态过大。影响范围可能是单节点，也可能是全集群。
• 人为故障：误删索引、错误执行 _close、误改副本数为0、快照恢复覆盖生产数据。这类故障往往绕过冗余机制，直接破坏数据。

硬件和网络故障靠副本与跨域部署抵御；软件故障靠资源隔离、版本管理和监控预警；人为故障则必须靠权限控制、快照保留和恢复演练来兜底。四类故障域不是并列关系，而是层层递进——副本能防住磁盘坏，却防不住 DELETE index。

从架构到灾备：关键判断点

把上面的结构落到灾备规划上，需要回答几个具体问题。第一，主节点是否满足多数派？3个专用主节点可容忍1台故障，2个则没有冗余，1个等于单点。第二，副本是否跨故障域？如果所有数据节点在同一机架，副本再多也挡不住机架断电。第三，协调节点是否成为瓶颈？高并发查询下，专用协调节点能避免数据节点被请求转发拖慢。

一个可参考的示例配置（属于教学假设，非实测结果）：3台专用主节点（4C8G）、6台数据节点（16C64G，SSD）、2台协调节点（8C16G），索引设3主分片1副本，通过 cluster.routing.allocation.awareness.attributes: rack_id 让主副本分布到不同机架。此时单台数据节点宕机，副本可提升为主分片，集群保持green；单机架断电，另一机架仍有完整副本，数据不丢。

最后要强调，故障域分析不是一次性工作。集群扩容、机房迁移、版本升级都会改变故障域边界。建议把节点角色、分片分布、副本位置、快照策略纳入同一张运维视图，定期用 _cat/allocation、_cat/shards 和集群健康API核对，确保“逻辑green”背后是真正的“物理冗余”。