elasticsearch的副本机制是怎么样的，什么情况下会丢失副本，什么时候会选举新的master

### 1. Elasticsearch 的副本机制 (Replica Mechanism) 副本机制是 Elasticsearch 实现数据冗余、高可用性和高吞吐量的基石。 #### 核心概念 1. **分片 (Shard)**：ES 将一个索引（Index）的数据水平切分成多个部分，每一部分就是一个分片。分片是 ES 中数据存储的最小单元。 2. **主分片 (Primary Shard)**：每个分片都有一个“主”版本，它负责处理所有的**写操作**（索引、更新、删除文档）。一个索引的主分片数量在创建时指定，后续不可修改。 3. **副本分片 (Replica Shard)**：副本分片是主分片的一个完整拷贝。它有两个主要作用： * **高可用性 (High Availability)**：当主分片所在的节点出现故障时，一个副本分片可以被提升（Promote）为新的主分片，从而保证数据的可用性，防止服务中断。 * **提升读性能 (Read Performance)**：搜索、聚合等**读操作**可以由主分片或任意一个副本分片来处理。通过将读请求分发到副本上，可以显著提升集群的查询吞吐量。 #### 工作流程 **写操作流程 (Write Operation):** 1. **路由**：客户端发送一个写请求（如 `POST /my_index/_doc`）到集群中的任意一个节点（这个节点被称为协调节点 Coordinating Node）。 2. **转发至主分片**：协调节点根据文档 ID 计算出该文档应该属于哪个主分片，然后将请求转发到持有该主分片的节点上。 3. **在主分片执行**：主分片节点接收请求，验证并执行操作，将数据写入自己的分片中。 4. **同步至副本**：操作成功后，主分片会**并行地**将该操作请求转发给它所有的副本分片。 5. **副本确认**：每个副本分片执行相同的操作，并将结果报告给主分片。 6. **响应客户端**：一旦**足够数量**的分片（主分片+副本分片）完成了操作，主分片节点就会向协调节点报告成功，协调节点再将成功响应返回给客户端。 * 这个“足够数量”由参数 `wait_for_active_shards` 控制，默认为1（即只要主分片成功即可），但可以设置为 `all` 或具体数字来确保数据写入多个副本后才返回，增强数据持久性。 **读操作流程 (Read Operation):** 读操作（如 `GET /my_index/_search`）相对简单。协调节点可以将请求轮询（Round-robin）分发到主分片或其任何一个副本分片上，从而分担负载。 --- ### 2. 什么情况下会丢失副本？ “丢失副本”通常意味着副本分片变为**未分配（Unassigned）**状态。这会使集群健康状态变为 **YELLOW**。 **集群健康状态 (Cluster Health):** * **GREEN**：所有主分片和副本分片都正常分配和工作。集群 100% 健康。 * **YELLOW**：所有主分片都正常，但至少有一个副本分片未分配。这意味着数据是完整的（没有数据丢失），但高可用性受到影响。如果此时对应的主分片也挂了，数据就会丢失。 * **RED**：至少有一个主分片未分配。这意味着部分数据不可用，某些查询会失败。这是最严重的状态。 **导致副本丢失（变为 YELLOW 状态）的主要原因：** 1. **节点离线 (Node Failure)**： * 这是最常见的原因。当一个持有副本分片的节点因为硬件故障、网络中断或进程崩溃而离线时，该节点上的所有副本分片都会“丢失”。 * **恢复机制**：Master 节点会检测到节点离线，并等待一段时间（默认为1分钟）。如果节点没有重新加入集群，Master 就会将这些丢失的副本在其他存活的节点上重新创建，并从对应的主分片那里复制数据。这个过程称为 **Replica Allocation**。 2. **网络分区 (Network Partition)**： * 集群中的一部分节点无法与 Master 节点通信。Master 会认为这些节点已经离线，从而将它们上面的副本标记为未分配。 3. **磁盘空间不足 (Disk Full)**： * 如果一个节点的磁盘使用率超过了设定的高水位线（`cluster.routing.allocation.disk.watermark.high`），ES 会尝试将该节点上的分片（包括副本）迁移到其他节点。如果找不到合适的节点，副本就可能变为未分配状态。 4. **手动操作**： * 管理员通过 API 关闭了某个索引 (`POST /my_index/_close`)。 * 通过集群设置排除了某个节点，ES 会将该节点上的分片迁移走。 **总结：** 丢失副本通常是暂时的。只要主分片还在，ES 强大的自愈能力就会在其他可用节点上重建丢失的副本，使集群最终恢复到 `GREEN` 状态。但如果在这个 `YELLOW` 状态的窗口期，对应的主分片也挂了，就会导致数据丢失（集群变为 `RED`）。 --- ### 3. 什么时候会选举新的 Master？ Master 节点是集群的大脑，负责管理集群状态（Cluster State），如创建/删除索引、跟踪节点、分配分片等。一个健康的集群在任何时候都只有一个 Master 节点。 **选举新 Master 的触发条件：** 1. **集群首次启动**：当集群中的多个符合 Master 资格的节点（Master-eligible nodes）首次互相发现时，它们会进行一次选举以决定第一个 Master。 2. **当前 Master 节点故障**： * Master 节点所在的服务器宕机或进程崩溃。 * Master 节点因网络问题与其他 Master-eligible 节点隔离。 * Master 节点发生长时间的 GC (Garbage Collection) 停顿，导致无法响应其他节点的 Ping 请求，被认为已经死亡。 #### Master 选举流程（7.x 及以后版本） 从 ES 7.0 开始，选举机制基于 Raft 共识算法，变得更加健壮和简单，有效避免了“脑裂”（Split-Brain）问题。 1. **候选者 (Master-eligible Nodes)**：只有在 `elasticsearch.yml` 中配置了 `node.roles: [ master, ... ]` (或旧版的 `node.master: true`) 的节点才有资格参与选举。 2. **法定人数 (Quorum)**：选举和任何集群状态的变更都需要得到**大多数**（Majority）Master-eligible 节点的同意。这个数量是 `(N / 2) + 1`，其中 N 是集群中 Master-eligible 节点的总数。 * 例如，如果有 3 个 Master-eligible 节点，法定人数就是 `(3 / 2) + 1 = 2`。 * 如果有 5 个，法定人数就是 `(5 / 2) + 1 = 3`。 3. **选举过程**： * 当一个节点发现联系不上 Master 时，它会发起一轮新的选举。 * 它会向所有其他 Master-eligible 节点发送投票请求。 * 其他节点会根据一些条件（如谁的数据更新、任期号更大等）来决定投票给谁。 * 一旦某个候选者获得了超过法定人数的选票，它就成为新的 Master。 * 新的 Master 会开始发布新的集群状态，其他节点则加入由新 Master 领导的集群。 **如何防止“脑裂” (Split-Brain)？** “脑裂”是指在一个网络分区中，集群被分成两个或多个部分，每个部分都以为自己是唯一的主集群，并选举出自己的 Master。这会导致数据不一致和严重问题。 在 7.x 之后，基于 Quorum 的机制从根本上解决了这个问题： * 假设有 3 个 Master-eligible 节点 (M1, M2, M3)。法定人数是 2。 * 如果 M1 (当前 Master) 与 M2, M3 发生网络隔离。 * M1 所在的分区只有它自己，无法满足 2 个节点的法定人数，因此它会自动**降级**（step down），不再接受任何写操作。 * M2, M3 所在的分区有两个节点，满足法定人数。它们会发现 Master M1 失联，并发起选举，从 M2 或 M3 中选出一个新 Master。 * 这样，整个集群在任何时候都只会有一个合法的 Master，因为它必须得到大多数节点的认可。 **最佳实践**：为了高可用和避免脑裂，生产环境中的 Master-eligible 节点数量应该是**奇数个，且至少为 3 个**。 ### 总结 * **副本机制**：通过主分片写、副本同步的方式，实现数据备份和读性能扩展。 * **副本丢失**：通常由节点离线引起，集群状态变为 `YELLOW`。ES 会自动在其他节点上重建副本，具备自愈能力。 * **Master 选举**：在 Master 节点故障时触发。7.x 版本后基于 Raft 算法，通过法定人数（Quorum）机制保证选举的唯一性和正确性，有效防止了“脑裂”问题。