Elasticsearch 已经有了 很好 的默认值, 特别是涉及到性能相关的配置或者选项。 如果你有疑问,最好就不要动它。有些 逻辑上的 配置在生产环境中是应该调整的。 这些调整可能会让你的工作更加轻松,又或者因为没办法设定一个默认值(它取决于你的集群布局)。
- 指定名字:Elasticsearch 默认启动的集群名字叫 elasticsearch 。 你最好给你的生产环境的集群改个名字,改名字的目的很简单, 就是防止某人的笔记本电脑加入了集群这种意外。修改elasticsearch.yml 文件里面的cluster.name和node.name,cluster.name最好是使用"项目名_环境",如account_test,node.name采用"项目名_ip后三位",如account_188。
#指定集群名称
cluster.name: account_test
#指定节点名称
node.name: account_188
#指定是否是主节点
node.master: true
#指定是否存储数据节点
node.data: true - 修改路径:默认情况下, Elasticsearch 会把插件、日志以及你最重要的数据放在安装目录下。这会带来不幸的事故, 如果你重新安装 Elasticsearch 的时候不小心把安装目录覆盖了。如果你不小心,你就可能把你的全部数据删掉了。
最好的选择就是把你的数据目录配置到安装目录以外的地方, 同样你也可以选择转移你的插件和日志目录。如
#通过逗号分隔指定多个目录。
path.data: /path/to/data1,/path/to/data2
#Path to log files:
path.logs: /path/to/logs
#Path to where plugins are installed:
path.plugins: /path/to/plugins - 最小主节点数:minimum_master_nodes 设定对你的集群的稳定 极其 重要。 当你的集群中有两个 masters(注:主节点)的时候,这个配置有助于防止 脑裂 ,一种两个主节点同时存在于一个集群的现象。
这个配置就是告诉 Elasticsearch 当没有足够 master 候选节点的时候,就不要进行 master 节点选举,等 master 候选节点足够了才进行选举。
此设置应该始终被配置为 master 候选节点的法定个数(大多数个)。法定个数就是 ( master 候选节点个数 / 2) + 1 。 这里有几个例子:
——如果你有 10 个节点(能保存数据,同时能成为 master),法定数就是 6 。
——如果你有 3 个候选 master 节点,和 100 个 data 节点,法定数就是 2 ,你只要数数那些可以做 master 的节点数就可以了。
——如果你有两个节点,你遇到难题了。法定数当然是 2 ,但是这意味着如果有一个节点挂掉,你整个集群就不可用了。 设置成 1 可以保证集群的功能,但是就无法保证集群脑裂了,像这样的情况,你最好至少保证有 3 个节点。可以通过修改elasticsearch.yml配置:
discovery.zen.minimum_master_nodes: 2
minimum_master_nodes (还有一些其它配置)允许通过 API 调用的方式动态进行配置。 当你的集群在线运行的时候,你可以这样修改配置:
PUT /_cluster/settings
{
“persistent” : {
“discovery.zen.minimum_master_nodes” : 2
}
} - 集群恢复方面的配置:当你集群重启时,几个配置项影响你的分片恢复的表现。 首先,我们需要明白如果什么也没配置将会发生什么。
想象一下假设你有 10 个节点,每个节点只保存一个分片,这个分片是一个主分片或者是一个副本分片,或者说有一个有 5 个主分片/1 个副本分片的索引。有时你需要为整个集群做离线维护(比如,为了安装一个新的驱动程序), 当你重启你的集群,恰巧出现了 5 个节点已经启动,还有 5 个还没启动的场景。
假设其它 5 个节点出问题,或者他们根本没有收到立即重启的命令。不管什么原因,你有 5 个节点在线上,这五个节点会相互通信,选出一个 master,从而形成一个集群。 他们注意到数据不再均匀分布,因为有 5 个节点在集群中丢失了,所以他们之间会立即启动分片复制。
最后,你的其它 5 个节点打开加入了集群。这些节点会发现 它们 的数据正在被复制到其他节点,所以他们删除本地数据(因为这份数据要么是多余的,要么是过时的)。 然后整个集群重新进行平衡,因为集群的大小已经从 5 变成了 10。
在整个过程中,你的节点会消耗磁盘和网络带宽,来回移动数据,因为没有更好的办法。对于有 TB 数据的大集群, 这种无用的数据传输需要 很长时间 。如果等待所有的节点重启好了,整个集群再上线,所有的本地的数据都不需要移动。
现在我们知道问题的所在了,我们可以修改一些设置来缓解它。 首先我们要给 ELasticsearch 一个严格的限制:
gateway.recover_after_nodes: 8
这将阻止 Elasticsearch 在存在至少 8 个节点(数据节点或者 master 节点)之前进行数据恢复。 这个值的设定取决于个人喜好:整个集群提供服务之前你希望有多少个节点在线?这种情况下,我们设置为 8,这意味着至少要有 8 个节点,该集群才可用。
现在我们要告诉 Elasticsearch 集群中 应该 有多少个节点,以及我们愿意为这些节点等待多长时间:
gateway.expected_nodes: 10
gateway.recover_after_time: 5m
这意味着 Elasticsearch 会采取如下操作:
等待集群至少存在 8 个节点
等待 5 分钟,或者10 个节点上线后,才进行数据恢复,这取决于哪个条件先达到。
这三个设置可以在集群重启的时候避免过多的分片交换。这可能会让数据恢复从数个小时缩短为几秒钟。
注意:这些配置只能设置在 config/elasticsearch.yml 文件中或者是在命令行里(它们不能动态更新)它们只在整个集群重启的时候有实质性作用。 - 使用单播发现:防止节点无意中加入集群,只有在同一台机器上运行的节点才会自动组成集群。
使用单播,你可以为 Elasticsearch 提供一些它应该去尝试连接的节点列表。 当一个节点联系到单播列表中的成员时,它就会得到整个集群所有节点的状态,然后它会联系 master 节点,并加入集群。
这意味着你的单播列表不需要包含你的集群中的所有节点, 它只是需要足够的节点,当一个新节点联系上其中一个并且说上话就可以了。如果你使用 master 候选节点作为单播列表,你只要列出三个就可以了。 配置方式有两种:
(1)在 elasticsearch.yml 文件中:discovery.zen.ping.unicast.hosts: [“host1”, “host2:port”]
(2)基于文件配置,在elasticsearch.yml 文件中discovery.zen.hosts_provider: file,在$ES_PATH_CONF创建文件unicast_hosts.txt,文件内容如下:
#没有指定端口用默认端口9300
10.10.10.5
10.10.10.6:9305
10.10.10.5:10005
#an IPv6 address
[2001:0db8:85a3:0000:0000:8a2e:0370:7334]:9301