Elasticsearch（二） 重要配置说明

Elasticsearch 已经有了 很好 的默认值， 特别是涉及到性能相关的配置或者选项。 如果你有疑问，最好就不要动它。有些 逻辑上的 配置在生产环境中是应该调整的。 这些调整可能会让你的工作更加轻松，又或者因为没办法设定一个默认值（它取决于你的集群布局）。

1. 指定名字：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
2. 修改路径：默认情况下， 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
3. 最小主节点数：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
   }
   }
4. 集群恢复方面的配置：当你集群重启时，几个配置项影响你的分片恢复的表现。 首先，我们需要明白如果什么也没配置将会发生什么。
   想象一下假设你有 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 文件中或者是在命令行里（它们不能动态更新）它们只在整个集群重启的时候有实质性作用。
5. 使用单播发现：防止节点无意中加入集群，只有在同一台机器上运行的节点才会自动组成集群。
   使用单播，你可以为 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