Important configuration changes
Elasticsearch already has good defaults, especially when it comes to performance-related configuration or options. If you're in doubt, it's best not to touch it. We've seen dozens of clusters destroyed by the wrong setup, because its managers always thought that changing one configuration or option could lead to a 100x improvement.
|
Note
|
Please read the entire article, all configuration items are equally important, regardless of the order of description, please read all configuration options and apply them to your cluster. |
Other databases may need tuning, but in general, Elasticsearch does not. If you run into performance issues, the solution is usually better data layout or more nodes. There are very few "magic configuration items" in Elasticsearch, and if they exist, we've optimized them for you!
In addition, some logical configuration should be adjusted in production environment. These tweaks may make your life easier, or because there is no way to set a default value (it depends on your cluster layout).
specified name
The cluster name that Elasticsearch starts by default is called elasticsearch . You'd better rename your production cluster. The purpose of the name change is simply to prevent someone's laptop from accidentally joining the cluster. A simple modification elasticsearch_production will be very worry-free.
You can modify in your elasticsearch.yml file:
cluster.name: elasticsearch_production
Again, it's a good idea to change your node name as well. As you may have discovered by now, Elasticsearch randomly assigns a name to your node when it starts up. You might find it funny, but not when it's 3 AM and you're still trying to remember which physical machine is Tagak the Leopard Lord.
What's more, these names are generated at startup, and every time a node is started, it gets a new name. This can make the log very confusing, because all the node names are constantly changing.
This might be annoying to you, we recommend giving each node a meaningful, clear, descriptive name, which you can also elasticsearch.yml configure in:
node.name: elasticsearch_005_data
path
By default, Elasticsearch will put plugins, logs, and your most important data in the installation directory. This can be an unfortunate accident if you accidentally overwrite the installation directory when you reinstall Elasticsearch. If you are not careful, you may delete all your data.
Don't laugh, we have seen this situation many times.
Your best bet is to configure your data directory somewhere other than the installation directory, but you can also choose to move your plugins and log directories.
Can be changed as follows:
path.data: /path/to/data1,/path/to/data2 (1)
# Path to log files:
path.logs: /path/to/logs
# Path to where plugins are installed:
path.plugins: /path/to/plugins
-
Note: You can specify multiple directories separated by commas.
Data can be saved to multiple different directories. If each directory is mounted on a different hard disk, this is a simple and efficient way to implement a floppy disk array (RAID 0). Elasticsearch will automatically stripe (Note: RAID 0 is also known as Stripe (stripe), in a disk array, data is striped across all hard disks in the disk array) data is separated into different directories, in order to improve performance.
|
Warning
|
Security and performance for multiple data paths
As with any disk array (RAID 0) configuration, only a single copy of the data is saved to the hard drive. If you lose a hard drive, you will definitely lose some of the data on that computer. With any luck your replicas are elsewhere in the cluster and can be used to restore data and recent backups. Elasticsearch attempts to keep all striped shards on a single drive to ensure minimal data loss. This means that The performance implications of this are: if you add multiple drives to improve the performance of a single index, it probably won't help much since most nodes only have one shard and such an active drive. Multiple data paths only help if you have many indexes/shards on a single node. Multiple data paths are a very handy feature, but at the end of the day, Elasticsearch is not software RAID. If you need a more advanced, robust, and flexible configuration, we recommend that you use software RAID instead of the multiple data path capabilities. |
Minimum number of master nodes
minimum_master_nodes 设定对你的集群的稳定 极其 重要。 当你的集群中有两个 masters（注：主节点）的时候，这个配置有助于防止 脑裂 ，一种两个主节点同时存在于一个集群的现象。
如果你的集群发生了脑裂，那么你的集群就会处在丢失数据的危险中，因为主节点被认为是这个集群的最高统治者，它决定了什么时候新的索引可以创建，分片是如何移动的等等。如果你有 两个 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
但是由于 ELasticsearch 是动态的，你可以很容易的添加和删除节点， 但是这会改变这个法定个数。 你不得不修改每一个索引节点的配置并且重启你的整个集群只是为了让配置生效，这将是非常痛苦的一件事情。
基于这个原因， minimum_master_nodes （还有一些其它配置）允许通过 API 调用的方式动态进行配置。 当你的集群在线运行的时候，你可以这样修改配置：
PUT /_cluster/settings
{
"persistent" : {
"discovery.zen.minimum_master_nodes" : 2
}
}
这将成为一个永久的配置，并且无论你配置项里配置的如何，这个将优先生效。当你添加和删除 master 节点的时候，你需要更改这个配置。
集群恢复方面的配置
当你集群重启时，几个配置项影响你的分片恢复的表现。首先，我们需要明白如果什么也没配置将会发生什么。
想象一下假设你有 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 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。
虽然组播仍然 作为插件提供， 但它应该永远不被使用在生产环境了，否在你得到的结果就是一个节点意外的加入到了你的生产环境，仅仅是因为他们收到了一个错误的组播信号。 对于组播 本身 并没有错，组播会导致一些愚蠢的问题，并且导致集群变的脆弱（比如，一个网络工程师正在捣鼓网络，而没有告诉你，你会发现所有的节点突然发现不了对方了）。
使用单播，你可以为 Elasticsearch 提供一些它应该去尝试连接的节点列表。 当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 master 节点，并加入集群。
这意味着你的单播列表不需要包含你的集群中的所有节点， 它只是需要足够的节点，当一个新节点联系上其中一个并且说上话就可以了。如果你使用 master 候选节点作为单播列表，你只要列出三个就可以了。 这个配置在 elasticsearch.yml 文件中：
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
关于 Elasticsearch 节点发现的详细信息，请参阅 Zen Discovery Elasticsearch 文献。