发现故障排除
编辑发现故障排除编辑
在大多数情况下，发现和选举过程会很快完成，并且主节点会长时间保持当选状态。
如果您的集群没有稳定的主节点，则其许多功能将无法正常工作，并且 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 进程的堆栈转储（例如，使用
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 进程的堆栈转储（例如，使用
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 进程的堆栈转储（例如，使用
jstack）或分析跟踪（例如，使用 Java Flight Recorder）来识别等待特定线程可用的长时间等待。节点热点线程 API 有时会提供有用信息，但请记住，此 API 还需要集群中所有节点上的多个
transport_worker和generic线程。该 API 可能会受到您尝试诊断的问题的影响。jstack更可靠，因为它不需要任何 JVM 线程。参与发现和集群成员资格的线程主要是
transport_worker和cluster_coordination线程，它们永远不应该长时间等待。Elasticsearch 日志中也可能有长时间等待线程的证据，尤其是来自org.elasticsearch.transport.InboundHandler的警告日志。有关更多信息，请参阅 网络线程模型。
节点加入集群后再次离开编辑
如果一个节点加入集群，但 Elasticsearch 确定它有故障，则该节点将再次从集群中删除。有关更多信息，请参阅 故障排除不稳定的集群。