1、ES集群千万不要一次性重启全部节点，会导致所有分片被置为 unassigned_shards，重启后需要大量时间重新分配切片。这期间集群会处于red状态，不能写入任何新数据。这在生产环境中会导致灾难性的后果。
2、所有，要采用轮流重启的方式。重启一个节点，等该节点重新加入并且集群状态变为green后，再重启下一个节点。而且建议最后重启master节点。如何查看master节点：
curl -XGET http://XXX:9200/_cat/nodes?v master列是*的就是主节点。
不要重启logstash，没有意义，还会导致kafka重平衡。
3、如果分片有副本的话，重启过程中，要临时关闭分片复制功能。
每个结点重启时，ElasticSearch集群的高可用和自平衡方案会自动在别的结点上复制该重启结点的分片，这定然导致了很大的IO和网络开支。所以要临时关闭这个功能。
curl -XPUT http://XXX:9200/_cluster/settings -d‘
{
"transient": {
"cluster.routing.allocation.enable": "none"
}
}’
重启后，记得恢复这个功能：
curl -XPUT http://XXX:9200/_cluster/settings -d‘
{
"transient" : {
"cluster.routing.allocation.enable" : "all"
}
}’
transient 临时：这些设置在集群重启之前一直会生效。一旦整个集群重启，这些设置就被清除。
4、一次性重启和轮流重启的实验对比
实验条件：三节点、每个切片没有备份，也没有关闭切片自动复制的功能
三个节点每个有2600个切片，每个节点磁盘使用量为 2T。
节点配置是 32核、64GB、5T SSD
1）一次性重启
操作，一次性重启所有节点上的es进程。
现象：所有节点变为unassigned_shards，集群变为red。
大概花了58分钟恢复到green。在重启后第50分钟的时候集群可以开始写入新的文档。
在恢复过程中，可以看到unassigned_shards逐渐变为acive_shards，达到100%后集群状态变成green。
实验结果：一次性重启全部3个节点，50分钟不可写，58分钟完全恢复。
2）只重启一台
操作：重启一个节点，观察现象。
现象：被重启节点上的切片变为unassigned_shards，集群变为red。
重启后，需要一段时间来将unassigned_shards变为acive_shards。
集群会在相当长的一段时间内不能保存新的文档。（但也不是非要等到green才能保存新文档，据不充分观察，active_shards_percent_as_number达到80%时就已经可以写入新文档了，该猜想仅对本次实验负责，不保证普遍性）
简单地说，每次只重启一台和一次性重启整个集群，会将一次较长的red持续时间划分成多份较短的red持续时间，两次red之间可以自由地留出一点时间来消费堆积的待写入数据。而且据观察，所有机器轮流重启导致的不可写入新文档的持续时间之和，小于一次性重启所有节点。
实验结果：只重启1个节点，另两个节点保持运行，10分钟不可写，20分钟完全恢复。
- 只重启一台，并且设置 “index.unassigned.node_left.delayed_timeout”: “5m”
Elasticsearch 可以推迟分片的分配。这可以让你的集群在重新分配之前有时间去检测这个节点是否会再次重新加入。本次实验将延迟时间设为5分钟（实际重启只需要1分钟左右）
实验结论：可能因为本集群的切片没有副本，一个节点退出，集群自然没有办法将退出节点上的切片重新分配。所以这个选项没用。
所以如果真的要重启ES集群的话，一定要选择轮流重启的方式。并且不要选择在生产时间进行。
做个粗略的估算，3节点集群下，每个节点2T数据-10分钟不可写，20分钟red。
================
死亡实验。
10节点集群、单机配置和上面3节点集群相同。
每节点数据3.4T，切片1260个。
重启一个节点，整个集群57分钟不可写+red。
真是太可怕了。
