一、故障描述
在完成ES集群部署，启动后，执行ES集群状态检查发现，集群报错503错误，如下所示：
环境：Elasticsearch 7.0.1；JDK版本1.8.0_211
二、处理过程
1、修改elasticsearch.yml将cluster初始化节点，三个都全写上。
修改cluster.initial_master_nodes: [“Namenode”, “Datanode2”]为
cluster.initial_master_nodes: [“Namenode”, “Datanode2”，“Datanode1”]
#Bootstrap the cluster using an initial set of master-eligible nodes:使用一组初始的可用主节点集合引导集群
2、重新启动
由上可知，ES集群已选举master完成。
3、验证：执行ES集群监控检查命令
curl -X GET "localhost:9200/_cat/health?v&pretty" ##返回如下
4、剩余2个节点也如上修改ES配置文件中的，
三、ES集群配置文件
1）位于 config 目录下的三个配置文件：
elasticsearch.yml ：用于配置 Elasticsearch
jvm.options ：用于配置 Elasticsearch JVM 设置
log4j2.properties：用于配置 Elasticsearch 日志记录的
2）ES集群发现配置
在投入生产之前，应该配置2个重要的集群发现和集群组成设置，以便集群中的节点可以相互发现并可成功选举出主节点。
1>discovery.seed_hosts配置项:当在同一主机配置es多实例时，启动集群会自动扫描 9300 to 9305的回环地址，连接其他es实例；但是如果es集群中的实例时分布在不通主机上时，就需要配置该配置项，指定组成ES集群的其他节点，这些节点都是可以成为Master的，从而提供给discovery 进程读取；此设置通常应包含集群中所有符合主节点条件的节点的地址。格式必须为host:port or host组成的数组或逗号隔开的字符串。端口默认对应 transport.profiles.default.port的设置。
2>cluster.initial_master_nodes:当第一次启动一个全新的 Elasticsearch 集群时，会有一个集群引导步骤，该步骤确定了在第一次选举中计票后符合成为主节点资格的节点集。在生产环境下，启动一个全新的ES集群时，必须明确列出应在第一次选举中计票的主合格节点。
3）ES集群heap size配置
默认情况下，Elasticsearch 会告诉 JVM 使用最小和最大大小为 1 GB 的堆内存。但是到生产环境时，该内存将无法满足实际，因此配置适合的堆大小以确保 Elasticsearch 有足够的可用堆非常重要。
在ES的config/ jvm.options文件中，ES将声明使用堆内存的情况，包括：Xms (minimum heap size) and Xmx (maximum heap size) 配置，且这2个需配置成大小一致的。Elasticsearch 可用的堆越多，它可以用于缓存的内存就越多。但过多的堆也会使ES遭受长时间的垃圾收集暂停。官方建议配置xmx为物理内存的50%左右即可。
-Xms2g
-Xmx2g
也可以通过ES_JAVA_OPTS来设置：
ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch
ES_JAVA_OPTS="-Xms4000m -Xmx4000m" ./bin/elasticsearch
另外，尽量保持在基于零的压缩 oops 的阈值以下；确切的截止值会有所不同，但在大多数系统上 26 GB 是安全的，但在某些系统上可能高达 30 GB。通过配置
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintCompressedOopsMode
启动ES集群，观察集群日志是否输出如下类似：
heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops
4）临时目录配置
可用环境变量$ES_TMPDIR指定。默认情况下，Elasticsearch启动脚本会在系统临时目录下创建一个自己的私有临时目录来使用。应该为 Elasticsearch 创建一个专用临时目录，该目录不会被清除旧文件和目录且应设置权限，以便只有运行 Elasticsearch 的用户才能访问它。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
