Elasticsearch重要文章之三：重要配置项的修改

Elasticsearch已经有很好的默认值，特别是涉及到性能相关的配置或者选项。若是你有什么拿不许的，最好就不要动它。咱们已经目击了数十个由于错误的设置而致使集群毁灭，由于它的管理者总认为他改动一个配置或者选项就能够带来100倍的提高。

注意：请阅读全文，全部的配置项都同等重要，和描述顺序无关，请阅读全部的配置选项，并应用到你的集群中。

其它数据库可能须要调优，但总得来讲，Elasticsearch不须要。若是你遇到了性能问题，最好的解决方法一般是更好的数据布局或者更多的节点。在Elasticsearch中有不多的”神奇的配置项”，若是存在，咱们也已经帮你优化了。

指定名字

Elasticsearch默认启动的集群名字叫elasticsearch，你最好给你的生产环境的集群改个名字，更名字的目的很简单，就是防止某我的的笔记本加入到了集群，形成意外。简单修改为elasticsearch_production ，会省掉屡次心痛~。
你能够在你的elasticsearch.yml中修改：
cluster.name: elasticsearch_production

一样，修改节点的名字也是明智的，就像你如今可能发现的那样，Elasticsearch会在你的节点启动的时候随机给它指定一个名字。这在你开发的时候可能以为很萌，可是当凌晨3点钟，你还在尝试会议哪台物理机是Tagak the Leopard Lord.的时候，你就不以为萌了。

更重要的是，这些名师是在启动的时候产生的，每次启动节点，它都会获得一个新的名字，这可使日志混淆，由于全部节点的名称都是不断变化的。
这些可能性都是很无聊的，咱们建议你给每一个及诶点一个有意义的名字-一个清楚的，描述性的名字，一样你能够在elasticsearch.yml中配置：
node.name: elasticsearch_005_data

路径

默认状况下，Eleasticsearch会把插件、日志以及你最重要的数据放在安装目录下。这会带来不幸的事故。即若是你从新安装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

注意：你能够经过逗号分隔指定多个目录。

数据能够保存到多个不一样的目录，每一个目录若是是挂载在不一样的硬盘，作一我的RAID 0是一个简单而有效的方式。Elasticsearch会自动把数据分隔到不一样的目录，以便提升性能。

最小主节点数

minimum_master_nodes的设定对你的集群的稳定及其重要，当你的集群中有两个masters的时候，这个配置有助于防止集群分裂。

若是你发生了一个集群分裂，你集群就会处在丢失数据的危险中，由于master节点是被认为是这个集群的最高统治者，它决定了何时新的索引能够建立，多少分片要移动等等。若是你有两个master节点，你的数据的完整性将得不到保证，由于你有两个master节点认为他们有集群的控制权。

这个配置就是告诉Elasticsearch当没有足够master候选节点的时候，就不要进行master选举，等master候选节点足够了才进行选举。

该配置必须应该配置成master候选节点的法定个数(大多数个),法定个数就是（master候选节点个数*2)+1. 这里有几个例子：
*若是你有10个节点（能保存数据，同时能成为master） 法定数就是6
*若是你有3个候选master，和100个数据节点，法定数就是2，你只要数数那些能够作master的节点数就能够了。
*若是你有两个节点，你遇到难题了，法定数固然是2，可是这意味着若是有一个节点挂掉，你整个集群就不可用了。设置成1能够保证集群的功能，可是就没法保证集群分裂了，想这样的状况，你最好至少保证有3个节点。

elasticsearch.yml中这样配置：
discovery.zen.minimum_master_nodes: 2

可是因为ELasticsearch是动态的，你能够很容易的添加和删除节点，这会改变这个法定个数，若是你不得不修改索引的节点的配置而且重启你的整个集群为了让配置生效，这将是很是痛苦的一件事情。
基于这个缘由，minimum_master_nodes （还有一些其它配置），容许经过API调用的方式动态进行配置，当你的集群在线运行的时候，你能够这样修改配置：
PUT /_cluster/settings
{
“persistent” : {
“discovery.zen.minimum_master_nodes” : 2
}
}

这将成为一个永久的配置，而且不管你配置项里配置的如何，这个将优先生效。当你添加和删除master节点的时候，你须要更改这个配置。

集群恢复方面的配置项

当你集群重启时，几个配置项影响你的分片恢复的表现。首先，咱们必须明白，若是什么也没配置将会发生什么。

想象一下假设你有10个节点，每一个节点保存一个分片，主分片或者副分片，也就是有一个有5个主分片/1个副本 的索引。你须要中止整个集群进行休整（举个例子，为了安装一个新的驱动程序）。当你重启你的集群，很天然会出现5个节点已经起动了，还有5个还没启动的场景。

假设其它五个节点出问题，或者他们根本没有收到当即重启的命令。不管什么缘由，你只要五个节点在线上。这五个节点会相互通讯，选出一个master，从而造成一个集群，他们注意到数据再也不均匀分布，由于有个节点在集群中丢失了，他们之间会立马启动分片复制。

最后，你的其它5个节点打开加入了集群，这些节点会发现他们的数据已经成为其它节点的副本了，因此他们删除本地数据（由于这份数据要么是多余的，要么是过期的）。而后整个集群从新进行平衡，由于集群的大小已经从5变成了10。

在整个过程当中，你的节点会消耗磁盘和网盘，来回移动数据，由于没有更好的理由。对于有上T数据的大集群，这种数据的传输须要很长时间。若是等待全部的节点重启好了，整个集群再上线，全部的本地的数据都不须要移动。

如今咱们知道问题的所在了，咱们能够修改一个小配置就能够缓解这个事情，首先咱们要给ELasticsearch一个严格的限制：
gateway.recover_after_nodes: 8

这将放置Elasticsearch进行数据恢复，在发现8个节点（数据节点或者master节点）以前。这个值的设定取决于我的喜爱: 整个集群提供服务以前你但愿有多少个节点在线？咱们设置为8， 这意味着至少要有8个节点，该集群才可用。

如今咱们要告诉Ealsticsearch集群中应该有多少个节点，而且咱们但愿集群须要多久等待全部节点：

gateway.expected_nodes: 10
gateway.recover_after_time: 5m

这意味着Elasticsearch会采起以下操做：
*至少等待8个节点上线
*等待5分钟，或者10个节点上线后，才进行数据恢复，这取决于哪一个条件先达到。

这三个设置能够在集群重启的时候避免过多的分片交换。这可能会让数据恢复从数个小时缩短为几秒钟。
这些配置只能设置在config/elasticsearch.yml文件中，或者是在命令行里（这些配置是没法东塔修改的），它们只在整个集群重启的时候有实质性做用。

最好使用单播代替组播

Elasticsearch默认是被配置成使用多播发现节点。多播就是经过在你的网络中发送UDP的ping请求以发现节点，其它Elasticsearch会收到这些ping请求而且进行响应，这样随后就会造成一个集群。
多播对于开发环境是很好的，你不须要作什么事情，打开一些节点，他们天然的会发现对方造成一个集群。
正是由于这种易用性，你在生产环境中必须禁掉它。否在你获得的结果就是一个节点意外的加入到了你的生产环境，由于他们收到了一个错误的组播信号。对于组播自己并无错。组播会致使一些愚蠢的问题，而且致使集群变的脆弱(例如：一个网络工程师正在捣鼓网络，而没有告诉你，你会发现全部的节点忽然发现不了对方了）。

在生产环境中，建议使用单播代替组播，也就是说为Elasticsearch提供一些它应该去尝试链接的节点列表。一旦这个节点联系到组播列表中的一员，它就会获得整个集群全部节点的状态，而后它会联系master节点，并加入集群。

这意味着你的单播列表不须要包含你的集群中的全部节点，它只须要包含足够一个新节点联系上其中一个而且说上话就ok了。若是你使用master候选节点做为单播列表，你只要列出三个就能够了。这个配置在elasticsearch.yml文件中：
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: [“host1”, “host2:port”]

备注：请确认你已经关闭了组播（discovery.zen.ping.multicast.enabled: false），不然它会和单播同时存在。