个人网站建站系统wordpress如何设置页面布局

本文是ES官方文档关于集群节点发现与互联互通的问题排查指南内容。

英文原文（官网）

集群节点发现是首要任务

集群互连，重中之重！

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

如果集群没有稳定的主节点，其许多功能将无法正常工作，并且Elasticsearch将会向客户端报告错误并在日志中记录。必须先修复主节点的不稳定问题，才能解决其他相关问题。在没有选出主节点或当前选出的主节点不稳定的情况下，解决任何其他问题都是不可能的。

如果集群有一个稳定的主节点，但部分节点无法发现或加入该主节点，那么这些节点将会向客户端报告错误并在它们的日志中记录。必须首先解决阻碍这些节点加入集群的问题，然后才能着手处理其他问题。在这些节点无法成功加入集群的情况下，解决它们所报告的任何其他问题是不可能的。

如果集群在几秒钟以上的时间内没有选出主节点，或者主节点不稳定，又或者部分节点无法发现或加入一个稳定的主节点，Elasticsearch将在其日志中记录相关信息来解释原因。若问题持续超过几分钟，Elasticsearch会在日志中记录更多详细信息。为了正确排查发现与选举问题，请从所有节点收集并分析至少涵盖五分钟的日志数据。

没有master被选中

当一个节点赢得主节点选举时，它会在日志中记录一条包含“elected-as-master”信息的消息，并且所有节点都会记录一条包含“master node changed”的消息，指出新当选的主节点。

如果没有选出主节点，且没有任何节点能够赢得选举，则所有节点将使用名为“org.elasticsearch.cluster.coordination.ClusterFormationFailureHelper”的日志器每隔10秒（默认间隔）重复记录关于此问题的消息。

主节点选举只涉及主节点候选节点，在这种情况下，应重点关注这些主节点候选节点。这些节点的日志将显示主节点选举的要求，例如发现特定数量的节点。在这些节点上的健康API也将提供有关当前状况的有用信息。

如果日志或健康报告表明Elasticsearch无法发现足够多的节点以形成法定人数（quorum），则必须解决阻止Elasticsearch发现缺失节点的原因。缺失的节点对于重建集群元数据是必需的。没有集群元数据，集群中的数据将失去意义。集群元数据存储在集群中一部分主节点候选节点上。如果无法发现法定人数，那么缺失的节点就是持有集群元数据的节点。

确保运行的节点数量足以形成法定人数（quorum），并且网络中任意两个节点之间都能相互通信。若选举问题持续超过几分钟，Elasticsearch会报告更多关于网络连接性的详细信息。如果无法启动足够节点来形成法定人数，建议启动一个新的集群并从最近的快照恢复数据。有关更多信息，请参阅基于法定人数的决策制定。

如果日志或健康报告显示Elasticsearch已经发现可能构成法定人数的节点集合，那么通常导致集群无法选举出主节点的原因在于其他某个节点无法发现法定人数。请检查其他主节点候选节点上的日志，并确保它们都已经成功发现足够节点以形成法定人数。

排查步骤

如果日志表明由于超时或网络相关问题导致发现或主节点选举失败，则按以下步骤缩小问题范围。

• 垃圾回收暂停会被Elasticsearch默认输出的GC日志记录下来，同时通常也会被主节点日志中的JvmMonitorService记录。利用这些日志确认节点是否存在高堆内存使用率以及长时间的GC暂停现象。如果存在这种情况，对于高堆内存使用的故障排查指南提供了一些进一步调查的建议，但通常您需要在堆内存使用高峰期间捕获堆转储，以便全面理解问题所在。

• 虚拟机暂停同样会影响同一主机上的其他进程。虚拟机暂停通常还会导致系统时钟出现不连续性，这一情况会在Elasticsearch日志中被报告出来。如果您发现有其他进程在同一时间暂停，或者观察到意外的时钟不连续性，那么请对运行Elasticsearch的基础架构进行深入调查。

• 抓包操作可以揭示系统级和网络级故障，特别是在所有相关节点同时捕获网络流量的情况下。这样应该能观察到节点间连接中的任何重传、丢包或其他延迟现象。

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

• 节点热线程API有时会提供有用的信息，但请注意，该API同时也要求集群中所有节点拥有一系列transport_worker和generic线程。因此，该API可能会受到您正试图诊断问题的影响。相比之下，jstack更为可靠，因为它不需要依赖JVM线程。

• 参与发现和集群成员资格管理的线程主要是transport_worker线程和cluster_coordination线程，这两类线程不应出现长时间等待的情况。在Elasticsearch日志中，尤其是来自org.elasticsearch.transport.InboundHandler的警告日志中，也可能会发现与线程长时间等待相关的证据。有关更多信息，请参阅网络线程模型。