Elasticsearch: 配置文件详解

Posted 2021-01-03 helloemk

elasticsearch.yml
官网：https://www.elastic.co/guide/en/elasticsearch/reference/current/modules.html
################################### Cluster ################################### 
# 代表一个集群,集群中有多个节点,其中有一个为主节点,这个主节点是可以通过选举产生的,主从节点是对于集群内部来说的. 
# es的一个概念就是去中心化,字面上理解就是无中心节点,这是对于集群外部来说的,因为从外部来看es集群,在逻辑上是个整体,你与任何一个节点的通信和与整个es集群通信是等价的。 
# cluster.name可以确定你的集群名称,当你的elasticsearch集群在同一个网段中elasticsearch会自动的找到具有相同cluster.name的elasticsearch服务. 
# 所以当同一个网段具有多个elasticsearch集群时cluster.name就成为同一个集群的标识. 
# cluster.name: es6.2 

#################################### Node ##################################### 
# 节点名称同理,可自动生成也可手动配置. 
# node.name: node-1

# 允许一个节点是否可以成为一个master节点,es是默认集群中的第一台机器为master,如果这台机器停止就会重新选举master. 任何主节点的节点（默认情况下所有节点）都可以被主选举过程选为主节点。
# node.master: true 

# 允许该节点存储数据(默认开启) 
# node.data: true 
# 注意：主节点必须有权访问该data/目录（就像data节点一样 ），因为这是集群状态在节点重新启动之间持续存在的位置。

# 允许该节点为摄取节点(默认开启) 
# node.ingest：true
# 配置为true将主节点和数据节点标记为“是有意义的”

# 开启跨群集搜索（默认启用）
# search.remote.connect：true

# 配置文件中给出了三种配置高性能集群拓扑结构的模式,如下： 
# 1. 如果你想让节点从不选举为主节点,只用来存储数据,可作为数据节点 
# node.master: true 
# node.data: false
# node.ingest: true

# 2. 如果想让节点成为主节点,且不存储任何数据,并保有空闲资源,可作为协调器 
# node.master：true 
# node.data：false 
# node.ingest：false 

# 3. 如果想让节点既不称为主节点,又不成为数据节点,那么可将他作为摄取节点,从节点中获取数据,生成搜索结果等 
# node.master: false 
# node.data: false 
# node.ingest: true

# 4. 仅作为协调器 
# node.master: false 
# node.data: false
# node.ingest: false

#################################### Paths #################################### 
# 数据存储位置(单个目录设置) 
# path.data: /var/data/elasticsearch
#path.data应将该设置配置为在Elasticsearch主目录之外定位数据目录，以便在不删除数据的情况下删除主目录！

# 日志文件的路径 
# path.logs: /var/log/elasticsearch 

#################################### 网络设置 #################################### 
# 节点将绑定到此主机名或IP地址
# network.host: 127.0.0.1

# 绑定到传入HTTP请求的端口
# http.port: 9200 
# 接受单个值或范围。如果指定了范围，则节点将绑定到范围中的第一个可用端口。默认为9200-9300

#################################### TCP传输 #################################### 
# 端口绑定节点之间的通信。
# transport.tcp.port: 9300
# 接受单个值或范围。如果指定了范围，则节点将绑定到范围中的第一个可用端口。默认为9300-9400

# transport.publish_port: 9300
# 与此节点通信时，群集中其他节点应使用的端口。当群集节点位于代理或防火墙之后并且transport.tcp.port不能从外部直接寻址时很有用。默认为通过分配的实际端口 transport.tcp.port

# transport.bind_host: 127.0.0.1
# 将传输服务绑定到的主机地址。默认为transport.host（如果设置）或network.bind_host

# transport.publish_host: 127.0.0.1 
# 发布集群中要连接到的节点的主机地址。默认为transport.host（如果设置）或network.publish_host

# transport.host: 127.0.0.1 
# 用于设置transport.bind_host和transport.publish_host默认为transport.host或network.host

# transport.tcp.connect_timeout: 30s
# 套接字连接超时设置（以时间设置格式）。默认为30s

# transport.tcp.compress: false
# 设置是否压缩tcp传输时的数据，默认为false,不压缩。

# transport.ping_schedule: 5s
# 安排常规ping消息以确保连接保持活动状态。默认为5s在传输客户端和-1（禁用）

#################################### 高级网络设置 #################################### 
#该network.host设置中的说明通常使用的网络设置 是快捷方式设定所述绑定的主机和发布主机在同一时间。在高级用例中，例如在代理服务器后运行时，可能需要将这些设置设置为不同的值：
# 绑定到哪个网络接口以侦听传入请求
# network.bind_host: 127.0.0.1
# 点可以绑定到多个接口，例如两个网卡，或站点本地地址和本地地址。默认为 network.host。

# network.publish_host: 127.0.0.1
# 发布主机是节点通告集群中其他节点的单个接口，以便这些节点可以连接到它。目前，Elasticsearch节点可能会绑定到多个地址，但只发布一个。如果未指定，则默认为“最佳”地址network.host，按IPv4 / IPv6堆栈首选项排序，然后按可访问性排序。如果您将其设置为 network.host多个绑定地址，但依赖于特定地址进行节点间通信，则应该明确设置 network.publish_host。transport.tcp.port

#################################### 高级TCP设置 #################################### 
# 任何使用TCP的组件（如HTTP和 传输模块）都共享以下设置：
# network.tcp.no_delay: true
# 启用或禁用TCP无延迟 设置。默认为true。

# network.tcp.keep_alive: true
# 启用或禁用TCP保持活动状态。默认为true。

# network.tcp.reuse_address: true
# 地址是否应该重复使用。默认为true在非Windows机器上。

# network.tcp.send_buffer_size
# TCP发送缓冲区的大小（以大小单位指定）。默认情况下不明确设置。

# network.tcp.receive_buffer_size
# TCP接收缓冲区的大小（以大小单位指定）。默认情况下不明确设置。

################################### Memory #################################### 
# bootstrap.memory_lock: true
# 设置为true来锁住内存。因为内存交换到磁盘对服务器性能来说是致命的，当jvm开始swapping时es的效率会降低，所以要保证它不swap

###################### 使用head等插件监控集群信息，需要打开以下配置项 ###########
# http.cors.enabled: true
# http.cors.allow-origin: "*"
# http.cors.allow-credentials: true

################################### Gateway ###################################
# 以下静态设置（必须在每个主节点上设置）控制刚刚选择的主服务器在尝试恢复群集状态和群集数据之前应等待的时间，修改后需要重启生效
# gateway.expected_nodes: 0
# 预计在集群中的（数据或主节点）数量。只要预期的节点数加入群集，恢复本地碎片就会开始。默认为0

# gateway.expected_master_nodes: 0
# 预计将在群集中的主节点的数量。一旦预期的主节点数加入群集，就会立即开始恢复本地碎片。默认为0

# gateway.expected_data_nodes: 0
# 预计将在群集中的数据节点的数量。只要预期数量的节点加入群集，就会开始恢复本地碎片。默认为0

# gateway.recover_after_time: 5m
# 设置初始化恢复过程的超时时间,超时时间从上一个配置中配置的N个节点启动后算起。默认为5m

################################## Discovery ##################################
#### 该配置十分重要,没有正确配置,可能无法构成集群
# 这是一个集群中的主节点的初始列表,当节点(主节点或者数据节点)启动时使用这个列表进行探测
# discovery.zen.ping.unicast.hosts: ["host1:port", "host2:port", "host3:port"]
# 默认为["127.0.0.1", "[::1]"]

# discovery.zen.ping.unicast.hosts.resolve_timeout: 5s
# 在每轮ping中等待DNS查找的时间量。指定为 时间单位。默认为5秒

# discovery.zen.ping_timeout: 3s
# 确定节点将多久决定开始选举或加入现有的群集之前等待,默认3s

# discovery.zen.join_timeout: 
# 一旦一个节点决定加入一个现有的已形成的集群，它将发送一个加入请求给主设备，默认值是ping超时的20倍。

# discovery.zen.minimum_master_nodes: 2
# 为防止数据丢失，配置discovery.zen.minimum_master_nodes设置（默认设置1）至关重要， 以便每个符合主节点的节点都知道 为了形成群集而必须可见的主节点的最小数量。
为了解释，假设您有一个由两个主节点组成的集群。网络故障会中断这两个节点之间的通信。每个节点都会看到一个主节点的节点......本身。随着minimum_master_nodes设置为默认1，这是足以形成一个集群。每个节点将自己选为新的主人（认为另一个主人资格的节点已经死亡），结果是两个集群，或者是一个分裂的大脑。直到一个节点重新启动后，这两个节点才会重新加入。任何已写入重新启动节点的数据都将丢失。
现在想象一下，您有一个具有三个主节点资格的节点的集群，并 minimum_master_nodes设置为2。如果网络拆分将一个节点与其他两个节点分开，则具有一个节点的一侧不能看到足够的主节点，并且会意识到它不能将自己选为主节点。具有两个节点的一侧将选择一个新的主控（如果需要）并继续正常工作。一旦网络拆分解决，单个节点将重新加入群集并再次开始提供服务请求。
该设置应该设置为符合主数据节点的法定数量：
（master_eligible_nodes / 2）+ 1

换句话说，如果有三个符合条件的节点，则最小主节点应设置为(3 / 2) + 1或2。

原文：https://blog.csdn.net/qq_34021712/article/details/79342668