全集群重启升级

Elasticsearch需要一个完整的集群重启跨主要版本升级时：从0.X至1.x或从1.x的2.x版本到 滚动升级不能跨主要版本的支持。

这个过程要一个完整的集群重启进行升级，如下所示：

第1步：禁用碎片分配

当您关闭一个节点，配置过程会立即尝试复制将原本节点集群中的其他节点上的碎片，造成大量浪费的I \/ O的。这可以通过关闭一个节点之前禁用分配来避免：

PUT \/_cluster\/settings

{

"persistent": {

"cluster.routing.allocation.enable": "none"

}

}

如果从0.90.x升级到1.x中，然后使用这些设置，而不是：

PUT \/ _cluster \/ settings

{

"persistent" : {

"cluster.routing.allocation.disable_allocation" : true ,

"cluster.routing.allocation.enable" : "none"

}

}

第2步：执行同步刷新

如果停止索引和发出碎片复苏将会更快 同步刷新的请求：

POST \/_flush\/synced

而同步刷新请求是“尽力而为”的操作。如果有任何未决的索引操作将失败，但它是安全的，如果需要多次重新发出请求。

第3步：关闭并升级所有节点编辑

停止集群中的所有节点上的所有Elasticsearch服务。每个节点都可以按照所描述的相同的程序进行升级。步骤3：停止和升级单个节点。

第4步：启动集群编辑

如果你有专门的主节点-节点与node.master设置为 真（默认值），node.data设置为假 -那么它是一个好主意，先启动它们。等待他们形成一个集群，并与数据节点继续之前选出的高手。您可以通过查看日志检查进度。

一旦主节点资格的最低数量 已经发现了对方，他们会形成一个集群，并选出一个高手。从上，在该点_cat /健康和_cat /节点 的API可以被用于监控节点加入集群：

GET _cat\/health

GET _cat\/nodes

使用这些API来检查所有节点成功加入群集。

第5步：等待黄色

只要每个节点加入群集，它会开始复苏存储在本地的任何主碎片。最初， _cat /健康要求将报告状态的红色，这意味着并非所有主碎片已经被分配。

一旦每个节点已恢复了当地的碎片时，状态会变成 黄色，这意味着所有主要碎片已被追回，但不是所有的副本碎片进行分配。这是可以预料的，因为分配仍然被禁用。

第6步：重新启用分配

延迟副本的分配直到所有的节点都加入群集允许主副本分配给已经具备局部碎片副本节点。在这一点上，与集群中的所有节点，它是安全的重新启用碎片分配：

PUT \/_cluster\/settings

{

"persistent": {

"cluster.routing.allocation.enable": "all"

}

}

如果从0.90.x升级到1.x中，然后使用这些设置，而不是：

PUT \/ _cluster \/ settings

{

"persistent" : {

"cluster.routing.allocation.disable_allocation" : false ,

"cluster.routing.allocation.enable" : "all"

}

}

群集现在开始分配副本碎片的所有数据节点。在这一点上是安全的恢复索引和搜索，但你的集群将恢复得更快，如果直到所有碎片已经康复可以延迟索引和搜索。

您可以监控与进度_cat /health和 _cat/recovery的API：

GET _cat\/health

GET _cat\/recovery

一旦状态列_cat/health产量已经达到绿 ​​色，所有要素和副本碎片已成功分配。