New

The executive guide to generative AI

Read more
About usPartnersSupport|Login
« 故障排除：不稳定集群 故障排除：监控 »
Elastic 文档 ›Elasticsearch 指南 [8.17] ›故障排除

故障排除：节点发现

编辑

故障排除：节点发现

编辑

在大多数情况下，节点发现和选举过程会很快完成，并且主节点会长期保持当选状态。

如果您的集群没有稳定的主节点，则其许多功能将无法正常工作，并且 Elasticsearch 会向客户端和其日志中报告错误。您必须先修复主节点的不稳定性，然后再解决其他问题。在没有选出的主节点或选出的主节点不稳定的情况下，将无法解决任何其他问题。

如果您的集群有一个稳定的主节点，但某些节点无法发现或加入它，则这些节点会向客户端和其日志中报告错误。您必须先解决阻止这些节点加入集群的障碍，然后再解决其他问题。在这些节点无法加入集群的情况下，将无法解决这些节点报告的任何其他问题。

如果集群在几秒钟以上没有选出主节点，主节点不稳定，或者某些节点无法发现或加入稳定的主节点，则 Elasticsearch 会在其日志中记录信息以解释原因。如果问题持续存在几分钟以上，Elasticsearch 将在其日志中记录其他信息。要正确排除节点发现和选举问题，请收集并分析来自所有节点的至少五分钟的日志。

以下各节描述了一些常见的节点发现和选举问题。

未选出主节点

编辑

当一个节点赢得主节点选举时，它会记录一条包含 elected-as-master 的消息，并且所有节点都会记录一条包含 master node changed 的消息，以标识新选出的主节点。

如果没有选出的主节点，并且没有节点可以赢得选举，则所有节点将使用名为 org.elasticsearch.cluster.coordination.ClusterFormationFailureHelper 的记录器反复记录有关该问题的消息。默认情况下，这种情况每 10 秒发生一次。

主节点选举仅涉及有资格成为主节点的节点，因此在这种情况下，请将注意力集中在有资格成为主节点的节点上。这些节点的日志将指示主节点选举的要求，例如发现一组特定的节点。这些节点上的 健康状况 API 也将提供有关情况的有用信息。

如果日志或健康状况报告表明 Elasticsearch 无法发现足够多的节点来形成法定人数，则您必须解决阻止 Elasticsearch 发现缺失节点的原因。需要缺失的节点来重建集群元数据。如果没有集群元数据，则集群中的数据将毫无意义。集群元数据存储在集群中一部分有资格成为主节点的节点上。如果无法发现法定人数，则缺失的节点是那些持有集群元数据的节点。

确保有足够多的节点在运行以形成法定人数，并且每个节点都可以通过网络与其他每个节点进行通信。如果选举问题持续存在几分钟以上，Elasticsearch 将报告有关网络连接的其他详细信息。如果您无法启动足够多的节点来形成法定人数，请启动一个新的集群并从最近的快照还原数据。有关更多信息，请参阅 基于仲裁的决策。

如果日志或健康状况报告表明 Elasticsearch *已*发现可能的节点法定人数，则集群无法选出主节点的典型原因是其他节点之一无法发现法定人数。检查其他有资格成为主节点的节点上的日志，并确保它们都已发现足够多的节点来形成法定人数。

如果日志表明节点发现或主节点选举由于超时或与网络相关的问题而失败，请按如下方式缩小问题范围。

  • GC 暂停记录在 Elasticsearch 默认发出的 GC 日志中，通常也由主节点日志中的 JvmMonitorService 记录。使用这些日志来确认节点是否正在经历高堆使用率和长时间的 GC 暂停。如果是这样，高堆使用率的故障排除指南 中提供了一些进一步调查的建议，但通常您需要捕获堆转储以及高堆使用率期间的 垃圾收集器日志，才能充分了解问题。
  • VM 暂停也会影响同一主机上的其他进程。VM 暂停通常也会导致系统时钟中断，Elasticsearch 会在其日志中报告该情况。如果您看到证据表明其他进程同时暂停，或者出现意外的时钟中断，请调查运行 Elasticsearch 的基础架构。
  • 数据包捕获将揭示系统级和网络级故障，尤其是当您在所有相关节点上同时捕获网络流量并将其与这些节点的 Elasticsearch 日志一起分析时。您应该能够观察到节点之间连接上的任何重传、数据包丢失或其他延迟。

  • 通过在相关日志消息出现前的几秒钟内获取主 Elasticsearch 进程的堆栈转储（例如，使用 jstack）或分析跟踪（例如，使用 Java Flight Recorder），可以识别出等待特定线程可用的长时间等待。

    节点热线程 API 有时会产生有用的信息，但请记住，此 API 还需要集群中所有节点上的多个 transport_worker 和 generic 线程。该 API 可能会受到您正在尝试诊断的问题的影响。jstack 更可靠，因为它不需要任何 JVM 线程。

    参与节点发现和集群成员关系的线程主要是 transport_worker 和 cluster_coordination 线程，它们永远不应该有长时间的等待。Elasticsearch 日志中可能也会有长时间等待线程的证据，尤其是在查看来自 org.elasticsearch.transport.InboundHandler 的警告日志时。有关更多信息，请参阅 网络线程模型。

已选出主节点但不稳定

编辑

当一个节点赢得主节点选举时，它会记录一条包含 elected-as-master 的消息。如果这种情况反复发生，则表示选出的主节点不稳定。在这种情况下，请关注有资格成为主节点的节点的日志，以了解为什么选举的获胜者停止成为主节点并触发另一次选举。如果日志表明主节点由于超时或与网络相关的问题而不稳定，请按如下方式缩小问题范围。

  • GC 暂停记录在 Elasticsearch 默认发出的 GC 日志中，通常也由主节点日志中的 JvmMonitorService 记录。使用这些日志来确认节点是否正在经历高堆使用率和长时间的 GC 暂停。如果是这样，高堆使用率的故障排除指南 中提供了一些进一步调查的建议，但通常您需要捕获堆转储以及高堆使用率期间的 垃圾收集器日志，才能充分了解问题。
  • VM 暂停也会影响同一主机上的其他进程。VM 暂停通常也会导致系统时钟中断，Elasticsearch 会在其日志中报告该情况。如果您看到证据表明其他进程同时暂停，或者出现意外的时钟中断，请调查运行 Elasticsearch 的基础架构。
  • 数据包捕获将揭示系统级和网络级故障，尤其是当您在所有相关节点上同时捕获网络流量并将其与这些节点的 Elasticsearch 日志一起分析时。您应该能够观察到节点之间连接上的任何重传、数据包丢失或其他延迟。

  • 通过在相关日志消息出现前的几秒钟内获取主 Elasticsearch 进程的堆栈转储（例如，使用 jstack）或分析跟踪（例如，使用 Java Flight Recorder），可以识别出等待特定线程可用的长时间等待。

    节点热线程 API 有时会产生有用的信息，但请记住，此 API 还需要集群中所有节点上的多个 transport_worker 和 generic 线程。该 API 可能会受到您正在尝试诊断的问题的影响。jstack 更可靠，因为它不需要任何 JVM 线程。

    参与节点发现和集群成员关系的线程主要是 transport_worker 和 cluster_coordination 线程，它们永远不应该有长时间的等待。Elasticsearch 日志中可能也会有长时间等待线程的证据，尤其是在查看来自 org.elasticsearch.transport.InboundHandler 的警告日志时。有关更多信息，请参阅 网络线程模型。

节点无法发现或加入稳定的主节点

编辑

如果有一个稳定的选出主节点，但一个节点无法发现或加入其集群，它将使用 ClusterFormationFailureHelper 记录器反复记录有关该问题的消息。受影响的节点上的 健康状况 API 也将提供有关情况的有用信息。受影响的节点和选出的主节点上的其他日志消息可能会提供有关该问题的其他信息。如果日志表明该节点由于超时或与网络相关的问题而无法发现或加入集群，请按如下方式缩小问题范围。

  • GC 暂停记录在 Elasticsearch 默认发出的 GC 日志中，通常也由主节点日志中的 JvmMonitorService 记录。使用这些日志来确认节点是否正在经历高堆使用率和长时间的 GC 暂停。如果是这样，高堆使用率的故障排除指南 中提供了一些进一步调查的建议，但通常您需要捕获堆转储以及高堆使用率期间的 垃圾收集器日志，才能充分了解问题。
  • VM 暂停也会影响同一主机上的其他进程。VM 暂停通常也会导致系统时钟中断，Elasticsearch 会在其日志中报告该情况。如果您看到证据表明其他进程同时暂停，或者出现意外的时钟中断，请调查运行 Elasticsearch 的基础架构。
  • 数据包捕获将揭示系统级和网络级故障，尤其是当您在所有相关节点上同时捕获网络流量并将其与这些节点的 Elasticsearch 日志一起分析时。您应该能够观察到节点之间连接上的任何重传、数据包丢失或其他延迟。

  • 通过在相关日志消息出现前的几秒钟内获取主 Elasticsearch 进程的堆栈转储（例如，使用 jstack）或分析跟踪（例如，使用 Java Flight Recorder），可以识别出等待特定线程可用的长时间等待。

    节点热线程 API 有时会产生有用的信息，但请记住，此 API 还需要集群中所有节点上的多个 transport_worker 和 generic 线程。该 API 可能会受到您正在尝试诊断的问题的影响。jstack 更可靠，因为它不需要任何 JVM 线程。

    参与节点发现和集群成员关系的线程主要是 transport_worker 和 cluster_coordination 线程，它们永远不应该有长时间的等待。Elasticsearch 日志中可能也会有长时间等待线程的证据，尤其是在查看来自 org.elasticsearch.transport.InboundHandler 的警告日志时。有关更多信息，请参阅 网络线程模型。

节点加入集群后又离开

编辑

如果一个节点加入集群，但 Elasticsearch 确定其存在故障，则会再次将其从集群中删除。有关更多信息，请参阅 故障排除：不稳定集群。

« 故障排除：不稳定集群 故障排除：监控 »