elasticsearch7.9.1配置说明 针对master、data和client节点说明

elasticsearch7.9.1配置说明

path.data和path.logs

cluster.name

node.name

network.host

discovery和集群功能设置

设置堆大小

JVM堆转储路径

临时目录

JVM致命错误日志

master、data和client节点

四种组合

总结

 

elasticsearch配置说明

path.data和path.logs

如果您使用.zip或.tar.gz存档，则data和logs 目录是子文件夹$ES_HOME。如果这些重要文件夹保留在其默认位置，则在将Elasticsearch升级到新版本时，存在删除它们的高风险。

在生产使用中，您肯定会想要更改数据和日志文件夹的位置：

path:
  logs: /var/log/elasticsearch
  data: /var/data/elasticsearch

该RPM和Debian发行版已经使用自定义路径，data和logs。

该path.data设置可以被设置为多条路径，在这种情况下，所有的路径将被用于存储数据（虽然属于单个碎片文件将全部存储相同的数据路径上）：

path:
  data:
    - /mnt/elasticsearch_1
    - /mnt/elasticsearch_2
    - /mnt/elasticsearch_3

cluster.name

一个节点只有在与集群中的所有其他节点有相同的cluster.name时才能加入集群。默认名称是elasticsearch，但是您应该将其更改为描述集群用途的适当名称。

cluster.name: logging-prod

确保不要在不同的环境中重用相同的群集名称，否则最终会导致节点加入错误的群集。

node.name

Elasticsearch使用node.name作为Elasticsearch特定实例的可读标识符，因此它包含在许多api的响应中。它默认为在Elasticsearch启动时计算机所具有的主机名，但可以在Elasticsearch中显式配置如下:

node.name: prod-data-2

network.host

默认情况下，Elasticsearch只绑定到环回地址，例如。127.0.0.1 (::1)。这足以在服务器上运行单个开发节点。

• tip: 实际上，可以从$ES_HOME 单个节点上的相同位置启动多个节点。这对于测试Elasticsearch形成集群的能力非常有用，但它不是推荐用于生产的配置。

为了在其他服务器上形成包含节点的集群，您的节点将需要绑定到非环回地址。虽然有许多 网络设置，但通常您需要配置的是 network.host：

network.host: 192.168.1.10

该network.host设置也了解一些特殊的值，比如 local，site，_global_和喜欢修饰:ip4和:ip6，其中的细节中可以找到的特殊值network.host。

• tip:只要您提供自定义设置network.host，Elasticsearch就会假定您正在从开发模式转移到生产模式，并将许多系统启动检查从警告升级到异常。有关更多信息，请参阅开发模式与生产模式。

discovery和集群功能设置

在开始生产之前，应该配置两个重要的发现和群集形成设置，以便群集中的节点可以相互发现并选择主节点。
discovery.seed_hosts
开箱即用，没有任何网络配置，Elasticsearch将绑定到可用的环回地址，并将扫描本地端口9300到9305以尝试连接到在同一服务器上运行的其他节点。这提供了自动集群体验，无需进行任何配置。

如果要在其他主机上形成包含节点的群集，则必须使用该 discovery.seed_hosts设置提供群集中其他节点的列表，这些节点符合主要条件且可能是实时且可联系的，以便为发现过程设定种子。此设置通常应包含群集中所有符合主节点的节点的地址。此设置包含主机数组或逗号分隔的字符串。每个值应采用host:port或的形式host（如果未设置，则port 默认为设置transport.profiles.default.port回落 transport.port）。请注意，必须将IPv6主机置于括号内。此设置的默认值为127.0.0.1, [::1]。

cluster.initial_master_nodes
当您第一次启动全新的Elasticsearch集群时，会出现一个集群引导步骤，该步骤确定在第一次轮训中统计的合格节点集。在开发模式下，如果未配置发现设置，则此步骤由节点本身自动执行。由于此自动引导本质上是不安全的，因此当您在生产模式下启动全新集群时，必须明确列出符合主要条件的节点。使用该cluster.initial_master_nodes设置设置此列表 。

discovery.seed_hosts：
   -  192.168.1.10:9300
   -  192.168.1.11  # 如果未指定，端口将默认为transport.profiles.default.port和回退 transport.port。
   -  seeds.mydomain.com #如果主机名解析为多个IP地址，则该节点将尝试发现所有已解析地址的其他节点。
cluster.initial_master_nodes： 
   -  master-node-a
   -  master-node-b
   -  master-node-c

• cluster.initial_master_nodes： 初始主节点应由其标识 node.name，默认为其主机名。确保值cluster.initial_master_nodes与node.name 确切匹配。如果使用完全限定的域名（例如 master-node-a.example.com节点名称），则必须在此列表中使用完全限定名称; 相反，如果node.name是一个没有任何尾随限定符的裸主机名，那么你还必须省略尾随限定符cluster.initial_master_nodes。

设置堆大小

默认情况下，Elasticsearch告诉JVM使用最小和最大大小为1 GB的堆。迁移到生产环境时，配置堆大小以确保Elasticsearch有足够的可用堆是很重要的。

Elasticsearch将通过（minimum heap size）和（最大堆大小）设置分配jvm.options中指定的整个堆 。您应该将这两个设置设置为彼此相等Xms Xmx

这些设置的值取决于服务器上可用的RAM量：

• 设置Xmx并且Xms不超过物理RAM的50％。Elasticsearch需要内存用于JVM堆以外的其他目的，为此留出空间很重要。例如，Elasticsearch使用堆外缓冲区进行有效的网络通信，依赖操作系统的文件系统缓存来有效访问文件，而JVM本身也需要一些内存。使用比使用该Xmx设置配置的限制更多的内存来观察Elasticsearch进程是正常的。

• 设置Xmx并且Xms不超过JVM用于压缩对象指针的阈值（压缩oops）; 确切的阈值变化但接近32 GB。您可以通过在日志中查找如下所示的行来验证您是否低于阈值：

  heap size [1.9gb], compressed ordinary object pointers [true]
  

• 理想情况下设置Xmx并且Xms不超过基于零的压缩oops的阈值; 确切的阈值会有所不同，但大多数系统上26 GB是安全的，但在某些系统上可能高达30 GB。您可以通过使用JVM选项启动Elasticsearch -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode并查找如下所示的行来验证您是否低于此阈值 ：

  heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops
  

  显示已启用从零开始的压缩oops。如果未启用从零开始的压缩oops，则会看到如下所示的行：

  heap address: 0x0000000118400000, size: 28672 MB, Compressed Oops with base: 0x00000001183ff000
  

Elasticsearch可用的堆越多，它可用于其内部缓存的内存就越多，但它为操作系统用于文件系统缓存的内存就越少。此外，较大的堆可能导致更长的垃圾收集暂停。

以下是如何通过jvm.options文件设置堆大小的示例：

-Xms2g  # 将最小堆大小设置为2g。
-Xmx2g  # 将最大堆大小设置为2g。

也可以通过环境变量设置堆大小。这可以通过注释掉来完成Xms，并Xmx设置在 jvm.options文件中，并通过设置这些值ES_JAVA_OPTS：

ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch  # 将最小和最大堆大小设置为2 GB。
ES_JAVA_OPTS="-Xms4000m -Xmx4000m" ./bin/elasticsearch # 将最小和最大堆大小设置为4000 MB。
为Windows服务配置堆不同于上面的堆。最初为Windows服务填充的值可以如上配置，但在安装服务后不同。有关其他详细信息，请参阅[Windows服务文档][3]。

JVM堆转储路径

默认情况下，Elasticsearch将JVM配置为将内存异常转储到默认数据目录（这 /var/lib/elasticsearch适用于RPM和Debian软件包发行版，以及data用于tar和zip归档文件分发的Elasticsearch安装根目录下的目录） 。如果这个路径是不适合接受堆转储，您应该修改的条目-XX:HeapDumpPath=...在 jvm.options。如果指定目录，JVM将根据正在运行的实例的PID为堆转储生成文件名。如果指定固定文件名而不是目录，则当JVM需要在内存不足异常上执行堆转储时，该文件不能存在，否则堆转储将失败。

GC日志
默认情况下，Elasticsearch启用GC日志。这些配置在 jvm.options默认位置和默认位置与Elasticsearch日志相同。默认配置每64MB轮换一次日志，最多可占用2GB的磁盘空间。

临时目录

默认情况下，Elasticsearch使用启动脚本在系统临时目录下创建的专用临时目录。

在某些Linux发行版上，系统实用程序将清除文件和目录（/tmp如果它们最近未被访问过）。如果长时间不使用需要临时目录的功能，则可能导致在Elasticsearch运行时删除专用临时目录。如果随后使用需要临时目录的功能，则会导致问题。

如果使用.deb或.rpm包安装Elasticsearch 并在其下运行，systemd那么Elasticsearch使用的专用临时目录将从定期清理中排除。

但是，如果您打算.tar.gz在Linux 上运行分发一段时间，那么您应该考虑为Elasticsearch创建一个专用的临时目录，该目录不在将从中清除旧文件和目录的路径下。此目录应具有权限集，以便只有运行Elasticsearch的用户才能访问它。然后$ES_TMPDIR在启动Elasticsearch之前将环境变量设置 为指向它。

JVM致命错误日志

默认情况下，Elasticsearch将JVM配置为将致命错误日志写入默认日志记录目录（这/var/log/elasticsearch适用于RPM和Debian软件包发行版，以及logs 针对tar和zip归档文件分发的Elasticsearch安装根目录下的目录 ）。这些是JVM在遇到致命错误（例如，分段错误）时生成的日志。如果该路径不适合于接收的日志，则应修改条目-XX:ErrorFile=...中 jvm.options到备用路径。

 

 

master、data和client节点

在生产环境下，如果不修改elasticsearch节点的角色信息，在高数据量，高并发的场景下集群容易出现脑裂等问题。

　　默认情况下，elasticsearch 集群中每个节点都有成为主节点的资格，也都存储数据，还可以提供查询服务。这些功能是由两个属性控制的。
　　　　1. node.master

　　　　2. node.data
　　默认情况下这两个属性的值都是true。

　　node.master：这个属性表示节点是否具有成为主节点的资格
　　注意：此属性的值为 true，并不意味着这个节点就是主节点。因为真正的主节点，是由多个具有主节点资格的节点进行选举产生的。所以，这个属性只是代表这个节点是不是具有主节点选举资格。

　　node.data：这个属性表示节点是否存储数据。

四种组合

　1. node.master: true AND node.data: true AND node.ingest: true

　　这种组合表示这个节点既有成为主节点的资格，又可以存储数据，还可以作为预处理节点，这个时候如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。
　　elasticsearch 默认是：每个节点都是这样的配置，在测试环境下这样做没问题。实际工作中建议不要这样设置，这样相当于 主节点 和 数据节点 的角色混合到一块了。

　2. node.master: false AND node.data: true AND node.ingest: false

　　这种组合表示这个节点没有成为主节点的资格，也就不参与选举，只会存储数据。这个节点我们称为 data(数据)节点。在集群中需要单独设置几个这样的节点负责存储数据。后期提供存储和查询服务

　3. node.master: true AND node.data: false AND node.ingest: false

　　这种组合表示这个节点不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点。这个节点我们称为master节点

　4. node.master: false AND node.data: false AND node.ingest: true

　　这种组合表示这个节点即不会成为主节点，也不会存储数据，这个节点的意义是作为一个 client(客户端)节点，主要是针对海量请求的时候可以进行负载均衡。在新版 ElasticSearch5.x 之后该节点称之为：coordinate 节点，其中还增加了一个叫：ingest 节点，用于预处理数据（索引和搜索阶段都可以用到），当然，作为一般应用是不需要这个预处理节点做什么额外的预处理过程，那么这个节点和我们称之为 client 节点之间可以看做是等同的，我们在代码中配置访问节点就都可以配置这些 ingest 节点即可。

总结

　　默认情况下，每个节点都有成为主节点的资格，也会存储数据，还会处理客户端的请求。在一个生产集群中我们可以对这些节点的职责进行划分。

　　建议集群中设置 3台 以上的节点作为 master 节点【node.master: true node.data: false node.ingest:false】，这些节点只负责成为主节点，维护整个集群的状态。
　　再根据数据量设置一批 data节点【node.master: false node.data: true node.ingest:false】，这些节点只负责存储数据，后期提供建立索引和查询索引的服务，这样的话如果用户请求比较频繁，这些节点的压力也会比较大
　　所以在集群中建议再设置一批 ingest 节点也称之为 client 节点【node.master: false node.data: false node.ingest:true】，这些节点只负责处理用户请求，实现请求转发，负载均衡等功能。

　　master节点：普通服务器即可(CPU 内存 消耗一般)

          主节点的主要职责是负责集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。虽然主节点也可以协调节点，路由搜索和从客户端新增数据到数据节点，但最好不要使用这些专用的主节点。一个重要的原则是，尽可能做尽量少的工作。

　　data   节点：主要消耗磁盘，内存

 

          数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。数据节点对 CPU、内存、IO 要求较高，在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。

　　client | ingest  节点：普通服务器即可(如果要进行分组聚合操作的话，建议这个节点内存也分配多一点)          

         当一个节点既不配置为主节点，也不配置为数据节点时，该节点只能处理路由请求，处理搜索，分发索引等操作，从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。