1.4.7 版本升级

Elasticsearch通常可以使用滚动升级过程，导致服务不中断。下面详细介绍如何执行滚动升级与集群的升级重启。Elasticsearch不是所有版本都可以直接升级。升级前请先查阅相关文档，然后进行数据备份，最好在测试环境下模拟一遍。升级可以参照以下内容：

□从0.90.x到2.x需要全集群重启。

□从1.x到2.x需要全集群重启。

□从2.x到2.y可以不用全部重启，使用滚动升级完成（y>x）。

插件问题，在升级的时候，同时要考虑到插件问题，最好插件的版本和Elasticsearch版本一致。

在每个节点上升级和重启的过程为：

1）关闭Elasticsearch。

2）升级Elasticsearch。

3）升级插件。

4）启动Elasticsearch。

下面介绍集群重启和滚动升级。

1.集群重启

1）关闭分片分配。当我们试图关闭一个节点的时候，Elasticsearch会立即试图复制这个节点的数据到集群中的其他节点上。这将导致大量的IO请求。在关闭该节点的时候可以通过设置一下参数来避免此问题的发生：

PUT /_cluster/settings
{
  "transient": {"cluster.routing.allocation.enable": "none"}
}

2）执行一个同步刷新。当停止一个索引的时候，分片的恢复会很快，所以要进行同步刷新请求。

POST /_flush/synced

同步刷新请求是非常有效的一种操作，当任何索引操作失败的时候，可以执行同步刷新请求，必要的时候可以执行多次。

3）关闭和升级所有节点。停止在集群中的所有节点上的服务。每一个节点都要进行单独升级。这个主要就是文件替换操作，注意保留日志目录。

4）启动集群。如果你有专门的主节点（node.master节点设置为true，node.data节点设置为false），则先启动主节点。等待它们形成一个集群，然后选择一个主数据节点进行启动。你可以通过查看日志来检查启动情况。通过下面命令可以监控集群的启动情况，检查所有节点是否已成功加入集群。

GET _cat/health
GET _cat/nodes

5）等待黄色集群状态。当节点加入集群后，它首先恢复存储在本地的主分片数据。最初的时候，通过_cat/health请求发现集群的状态是红色，意味着不是所有的主分片都已分配。当每个节点都恢复完成后，集群的状态将会变成黄色，这意味着所有主分片已经被找到，但是并不是所有的副本分片都恢复。

6）重新分配。延迟副本的分配直到所有节点都加入集群，在集群的所有节点，可以重新启用碎片分配：

PUT /_cluster/settings
{
  "persistent": {"cluster.routing.allocation.enable": "all"}
}

这个时候集群将开始复制所有副本到数据节点上，这样可以安全地恢复索引和搜索。如果你能延迟索引和搜索直到所有的分片已经恢复，这样可以加快集群的恢复。可以通过下面API监控恢复的进度和健康情况：

GET _cat/health
GET _cat/recovery

最后当集群的状态出现绿色的时候，表示本次集群升级全部完成。

2.滚动升级

滚动升级允许Elasticsearch集群升级一个节点，同时又不影响系统的使用。在同一个集群中的所有节点的版本最好保持一致，否则可能会产生不可预知的后果。滚动升级的步骤如下：

1）关闭分片分配。当我们视图关闭一个节点的时候，Elasticsearch会立即试图复制这个节点的数据到集群中的其他节点上。这将导致大量的IO请求。在关闭该节点的时候可以通过设置一下参数来避免此问题的发生。

PUT /_cluster/settings
{
  "transient": {"cluster.routing.allocation.enable": "none"}
}

2）停止不必要的索引和执行同步刷新（可选）。你可以在升级过程中继续索引。如果，暂时停止不必要的索引碎片，但它恢复要快得多。所以可以执行同步刷新操作：

POST /_flush/synced

同步刷新请求是非常有效的一种操作，当任何索引操作失败的时候，可以执行同步刷新请求，必要的时候可以执行多次。

3）停止和升级一个节点。在启动升级前，将节点中的一个节点关闭。可以通过绿色解压安装或者通过RPM等安装包安装。不管是解压安装还是压缩包安装都要保留之前的数据文件不能被破坏。可以在新的目录中安装，把path.conf和path.data的位置指向之前的数据。

4）启动升级节点。启动“升级”节点，并通过接口检查是否正确：

GET _cat/nodes

5）启用共享配置。一旦节点加入集群，在节点重新启用碎片分配：

PUT /_cluster/settings
{
  "transient": {"cluster.routing.allocation.enable": "all"}
}

6）等待节点恢复。应该在集群下一个节点升级之前完成碎片分配。可以通过以下接口进行检查：

GET _cat/health

等待的状态栏从黄到绿色。状态绿色意味着所有主分片和副本分片已经完成分配。

一旦另一个节点升级，副本将被分配，集群的健康状态将达到绿色。

没有同步刷新碎片可能需要一些时间来恢复。恢复的状态和每个节点的监控可以用以下接口：

GET _cat/recovery

如果你停止了索引，那么恢复索引的恢复是安全的。

7）重复其他节点。当集群是稳定的，节点已经恢复，重复上述步骤，把所有剩余的节点进行升级。