MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

ElasticSearch中allocation到recovery的流程衔接

2024-03-245.5k 阅读

ElasticSearch 简介

Elasticsearch 是一个分布式、RESTful 风格的搜索和数据分析引擎，旨在快速存储、搜索和分析大量数据。它基于 Lucene 库构建，提供了简单易用的 API 来处理各种类型的数据，包括结构化、半结构化和非结构化数据。Elasticsearch 常用于实现全文搜索、日志分析、实时数据分析等场景。

节点角色与分配策略

在 Elasticsearch 集群中，不同的节点承担着不同的角色，这些角色对 allocation 和 recovery 流程有着重要影响。

节点角色

  1. Master 节点：负责集群的管理工作，例如创建或删除索引，跟踪哪些节点是集群的一部分，并决定分片分配到哪些节点。Master 节点通过选举产生，并且集群正常运行期间，只有一个主节点负责集群级别的操作。
  2. Data 节点：负责存储实际的数据，并执行数据相关的操作，如增删改查、搜索和聚合。数据节点的资源（如磁盘、内存、CPU）直接影响到数据存储和检索的性能。
  3. Ingest 节点：在数据被索引之前对其进行预处理。它可以执行一系列的转换操作，例如提取 IP 地址、移除敏感信息等。
  4. Coordinating 节点：负责处理客户端请求，将请求转发到合适的数据节点，并收集和合并数据节点返回的结果。每个节点默认都可以作为 Coordinating 节点。

分配策略

Elasticsearch 使用复杂的分配策略来决定将分片分配到哪个节点上。主要考虑以下因素：

  1. 节点负载：包括 CPU、内存、磁盘 I/O 和网络带宽等方面的负载。Elasticsearch 倾向于将分片分配到负载较低的节点上，以平衡集群的整体负载。
  2. 节点属性：可以通过设置节点的自定义属性（如 rack_id、zone 等）来影响分配策略。例如，可以使用 rack_id 属性确保不同副本分片分布在不同的机架上，以提高容灾能力。
  3. 数据平衡：确保数据在各个数据节点上均匀分布，避免出现数据倾斜问题。

Allocation 流程详解

Allocation 是指 Elasticsearch 将分片分配到集群中各个节点的过程。这一过程由 Master 节点主导，涉及多个步骤和决策。

1. 集群状态更新

当集群发生变化（例如节点加入、离开，索引创建、删除等）时，Master 节点会更新集群状态。集群状态包含了集群的所有元数据信息，如索引信息、节点信息、分片分配信息等。Master 节点会将新的集群状态广播给所有节点。

2. 分配决策

Master 节点根据当前集群状态和分配策略，决定将哪些分片分配到哪些节点上。这个决策过程会考虑前面提到的节点负载、节点属性等因素。例如，对于一个新创建的索引，Master 节点会计算每个数据节点的负载情况，并选择负载较低的节点来分配主分片和副本分片。

3. 发送分配命令

一旦 Master 节点做出分配决策，它会向目标节点发送分配命令。目标节点收到命令后，会开始准备接收和存储相应的分片数据。

代码示例：查看分配决策日志

在 Elasticsearch 中，可以通过设置日志级别来查看分配决策相关的日志。在 elasticsearch.yml 文件中，将 logger.org.elasticsearch.cluster.allocation 的日志级别设置为 DEBUG：

logger.org.elasticsearch.cluster.allocation: DEBUG

重启 Elasticsearch 后，在日志文件中可以看到类似以下的分配决策日志：

[2023-10-01T12:00:00,000][DEBUG][o.e.c.a.AllocationService] [node1] updating allocation for [my_index][0] from [UNASSIGNED] to [ASSIGNED] on [node2]

上述日志表明，my_index 索引的第 0 个分片从未分配状态变为分配到 node2 节点。

Recovery 流程详解

当分片被分配到目标节点后，就会进入 recovery 阶段。Recovery 的目的是在目标节点上重建分片的数据，使其与源分片的数据保持一致。

1. 本地 Recovery（Local Recovery）

如果是新创建的索引，或者源分片不可用（例如源节点故障），目标节点会执行本地 recovery。在本地 recovery 过程中，目标节点会从其他副本分片或者持久化存储（如磁盘上的快照）中获取数据来重建分片。

2. 远程 Recovery（Remote Recovery）

如果源分片可用，目标节点会执行远程 recovery。远程 recovery 是从源分片所在的节点复制数据到目标节点。这一过程分为以下几个步骤：

  • 初始化阶段：目标节点向源节点发送 recovery 请求，请求中包含了需要恢复的分片信息。
  • 数据传输阶段：源节点开始将数据发送给目标节点。数据传输采用分段传输的方式，以减少网络拥塞。
  • 同步阶段：目标节点接收到数据后，会进行校验和验证。如果数据校验通过，目标节点会将数据应用到本地的分片副本上。

代码示例：监控 Recovery 进度

可以使用 Elasticsearch 的 API 来监控 recovery 的进度。例如，通过以下命令可以查看指定索引的 recovery 状态：

GET /my_index/_recovery

返回结果类似如下：

{
  "my_index": {
    "shards": {
      "0": {
        "stage": "DONE",
        "primary": true,
        "source": {
          "type": "LOCAL",
          "node": "node1"
        },
        "target": {
          "type": "LOCAL",
          "node": "node2"
        },
        "files": {
          "total": 1,
          "recovered": 1
        },
        "bytes": {
          "total": 1024,
          "recovered": 1024
        }
      }
    }
  }
}

上述结果表明，my_index 索引的第 0 个分片已经完成 recovery，并且是通过本地 recovery 方式完成的。

Allocation 到 Recovery 的流程衔接

Allocation 和 Recovery 是紧密相连的两个过程，Allocation 为 Recovery 提供了目标节点和分片分配信息，而 Recovery 则是在目标节点上实际重建分片数据的过程。

1. 分配决策触发 Recovery

当 Master 节点完成分配决策并向目标节点发送分配命令后，目标节点接收到命令就会触发 Recovery 流程。如果是副本分片的分配，目标节点会根据分配信息找到源分片所在的节点，并发起远程 recovery 请求。

2. 状态同步与反馈

在 Recovery 过程中，目标节点会不断向 Master 节点反馈 recovery 的状态。Master 节点会根据这些反馈信息更新集群状态，例如将分片的状态从 ALLOCATING 改为 RECOVERING，当 recovery 完成后，再将状态改为 STARTED。

3. 故障处理与重新分配

如果在 Recovery 过程中出现故障（例如网络中断、源节点故障等），目标节点会向 Master 节点报告故障。Master 节点会根据故障情况决定是否重新分配分片。如果源节点只是暂时不可用，Master 节点可能会等待一段时间后重试 recovery；如果源节点永久性故障，Master 节点会重新选择其他可用的副本分片作为源分片，重新发起 recovery。

代码示例：模拟故障处理

可以通过模拟节点故障来观察 Elasticsearch 的故障处理和重新分配机制。首先，使用以下命令获取当前集群中的节点信息：

GET /_cat/nodes

假设当前集群中有 node1、node2 和 node3 三个节点，并且 my_index 索引的主分片位于 node1，副本分片位于 node2。现在模拟 node1 故障：

POST /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._name": "node1"
  }
}

上述命令会将 node1 排除在分配范围之外，模拟节点故障。此时，Elasticsearch 会检测到主分片不可用，并将 node2 上的副本分片提升为主分片，然后重新分配一个副本分片到 node3。通过查看 /_cat/shards 命令的输出，可以观察到分片的重新分配情况：

GET /_cat/shards/my_index

输出结果类似如下：

my_index 0 p STARTED 1 1024b node2
my_index 0 r STARTED 1 1024b node3

从输出结果可以看出，node2 上的副本分片已经提升为主分片，并且在 node3 上重新分配了一个副本分片。

影响 Allocation 到 Recovery 流程的因素

  1. 网络带宽：Allocation 和 Recovery 过程都依赖网络进行数据传输。如果网络带宽不足，会导致分配命令传输延迟以及 recovery 过程中的数据复制缓慢。可以通过监控网络带宽使用情况，合理配置网络资源来优化流程。例如，确保数据节点之间有足够的带宽，避免网络成为瓶颈。
  2. 磁盘 I/O：Recovery 过程中需要将数据写入目标节点的磁盘。如果磁盘 I/O 性能低下，会导致 recovery 速度变慢。可以选择高性能的磁盘（如 SSD），并优化磁盘 I/O 配置，如调整磁盘队列深度、优化文件系统参数等。
  3. 节点负载：前面提到，Allocation 过程会考虑节点负载。在 Recovery 过程中，节点负载也会影响数据处理速度。如果目标节点负载过高，可能无法及时处理传入的数据，导致 recovery 延迟。可以通过监控节点的 CPU、内存、磁盘 I/O 和网络负载情况，合理调整节点资源分配，确保节点在可承受的负载范围内运行。

常见问题与解决方法

  1. 分配失败：可能原因包括节点负载过高、磁盘空间不足、网络故障等。解决方法是检查节点状态，释放磁盘空间，修复网络问题，并根据节点负载情况调整分配策略。例如，可以通过 /_cat/nodes?v 命令查看节点的负载情况，通过 /_cat/health 命令查看集群的健康状态。
  2. Recovery 超时：这可能是由于网络不稳定、数据量过大或者源节点性能问题导致的。解决方法包括优化网络配置，增加网络带宽，对大数据量的分片进行分段 recovery，以及检查源节点的性能并进行优化。可以通过调整 indices.recovery.max_bytes_per_sec 参数来控制 recovery 过程中的数据传输速度，避免网络拥塞。
  3. 数据不一致：在 Recovery 过程中，如果数据校验失败，可能会导致数据不一致。这可能是由于网络传输错误、磁盘损坏等原因造成的。解决方法是重新进行 recovery，确保网络和磁盘的稳定性。可以通过设置 indices.recovery.file_checksum 参数为 true 来启用数据校验和验证，确保数据的一致性。

总结

Elasticsearch 中 Allocation 到 Recovery 的流程衔接是一个复杂而关键的过程，涉及到集群状态管理、分配策略、数据传输和故障处理等多个方面。深入理解这一流程，对于优化 Elasticsearch 集群性能、提高数据可靠性具有重要意义。通过合理配置节点角色、优化分配策略、监控和调整网络与磁盘性能等措施，可以确保 Allocation 和 Recovery 过程的高效、稳定运行。在实际应用中，还需要根据具体的业务需求和数据特点，灵活调整相关参数和配置，以充分发挥 Elasticsearch 的优势。同时，及时处理常见问题，如分配失败、Recovery 超时和数据不一致等，能够保障集群的正常运行，为用户提供可靠的搜索和数据分析服务。