• 文章名称：Elasticsearch Reference[2.2]
• 原文地址：https://www.elastic.co/guide/en/elasticsearch/reference/2.2/setup-upgrade.html
• 译者：code4j

升级

升级前请注意：

• 参考版本变化文档。
• 升级前请在在开发环境测试升级版本。
• 升级前备份数据。不做备份的话是没法回滚到上一版的。

Elasticsearch通常可以使用滚动升级步骤，服务不会中断。这章详细介绍如何进行滚动升级和停机升级。

当前版本是否支持滚动升级，请参照如下表格：

升级前	升级后	支持的升级方式
0.90.x	2.x	停集群升级
1.x	2.x	停集群升级
2.x	2.y	滚动升级(y>x)

---

备份你的数据

升级之前请经常做备份，这样出了问题你可以回滚。升级有时候还包括Lucene版本升级，Lucene升级后更新的索引可能在原来版本的Elasticsearch上跑不起来。

备份1.0往后的版本

在1.0往后的版本做备份，使用快照这一特性会方便很多，详细指示看这里：backup and restore with snapshots。

备份0.9及以前的版本

备份0.90.x版本步骤如下：

第一步：

下面这一步防止备份的时候索引刷新到磁盘：

PUT /_all/_settings
{
  "index": {
    "translog.disable_flush": "true"
   }
}

第二步：

下面这步防止集群备份的时候，数据从一个节点平衡到另一个节点。

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

第三步：备份你的数据

等再平衡和索引刷新禁用后，用你喜欢的方法开始备份数据（打成tar包，使用存储快照或者备份软件）

第四步：重新打开再平衡和索引刷新

当备份完成，不需要再从Elasticsearch读取数据后，必须要重新打开再平衡和索引刷新：

PUT /_all/_settings
{
  "index": {
    "translog.disable_flush": "false"
  }
}

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

---

滚动升级

滚动升级允许Elasticsearch集群一个节点一个节点升级，不需要停机。集群中不支持同时运行多个版本，因为分片不会从新版本分配到旧版本的节点上。

从这个列表中检查当前版本的ES是否支持滚动升级。

滚动升级步骤如下：

第一步：禁用分片再平衡

当你关闭一个节点时，分片分配进程将分片从当前节点复制到集群另一个节点上，这将会浪费大量的I/O操作。可以在关闭节点前禁用这个特性：

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

第二步：停止不必要的索引，并执行同步刷新（这一步可选）

你可以在升级期间愉快的进行索引操作，当然，如果你使用如下命令，停止不必要的索引，并执行同步刷新，分片恢复速度会更快：

POST /_flush/synced

同步刷新是锦上添花的操作。如果出现索引挂起的现象操作就会失败，为了安全起见有必要多试几次。

第三步：单个节点停机并升级

升级前关闭一个节点。

注意：当使用zip或tar包升级，默认情况下Elasticsearch home目录下的config，data，log，plugins等目录都会被覆盖。
最好解压到不同的目录，这样升级期间就不会删除原来的目录了。自定义的目录可以通过path.conf和path.data来设置。
RPM或DEB包会把目录放到 合适的位置。

使用rpm/deb安装包升级：

• 使用rpm或dpkg安装新包，所有的目录都会被放到合理的位置，配置文件不会被覆盖。

使用zip或tar包解压安装：

• 解压安装包，确保不要覆盖config和data目录。
• 从旧的安装目录拷贝conf目录到新安装目录，或者使用--path.conf选项到外部的config目录
• 从旧的安装目录拷贝data目录到新的安装目录，或修改config/elasticsearch.yml中的path.data设置data目录为原来的目录。

第四步：启动升级过的节点

启动升级后的节点并确认加入到集群中，可以通过日志或下面的命令来确认：

GET _cat/nodes

第四步：重新打开分片再平衡

当节点加入集群后，使用以下命令重启分片再平衡：

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

第六步：等待节点恢复正常

等待集群分片平衡结束后，再升级下一个节点。这一过程可以使用下面的命令检查：

GET _cat/health

等到status这一列由yellow变成green，Green表示主分片和副本都分配完了。

重点：滚动升级过程中，高版本上的主分片不会把副本分配到低版本的节点，因为高版本的数据格式老版本不认。
如果高版本的主分片没法分配副本，换句话说如果集群中只剩下了一个高版本节点，那么节点就保持未分配的状态，集群健康会保持yellow。
这种情况下，检查下有没有初始化或分片分配在执行。
一旦另一个节点升级结束后，分片将会被分配，然后集群状态会恢复到green。

没有使用同步刷新的分片恢复时间会慢一点。分片的状态可以通过_cat/recovery
请求监控：

GET _cat/recovery

第七部：重复上述步骤

当集群稳定并且节点恢复后，对剩下的节点重复上述过程。

---

停集群升级

当升级跨越大版本的Elasticsearch时，需要停集群重启：从0.x到1.x或1.x到2.x等。滚动升级不支持跨大版本的集群。
按照以下步骤进行停机群升级：

第一步：禁用分片分配

当你关闭一个节点时，分片分配进程将分片从当前节点复制到集群另一个节点上，这将会浪费大量的I/O操作。可以在关闭节点前禁用这个特性：

PUT /_cluster/settings
{
  "transient": {
    "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"
  }
}

第二步：执行同步刷新

停止不必要的索引，并执行同步刷新，分片恢复速度会更快：

POST /_flush/synced

同步刷新是锦上添花的操作。如果出现索引挂起的现象操作就会失败，为了安全起见有必要多试几次。

第三步：关闭并升级全部的节点：

关闭集群全部节点的ES服务，每个节点使用和 滚动重启 一样的方法升级每个节点。

第四步：启动集群

如果你有专门的master节点群（master节点就是node.master为true并且node.data为false的节点），最好先启动它们。等待它们形成集群并选举出主节点。这个过程可以通过日志检查。

一旦达到 最小可选举主节点个数时，将会形成一个集群并选举出主节点。然后就可以通过_cat/health 和 _cat/nodes API监控节点加入鸡群的情况：

GET _cat/health
GET _cat/nodes

使用上述API检查节点是否成功加入集群。

第五步：等待集群恢复至yellow

只要节点加入集群，节点上的主分片就开始在本地恢复。最初_cat/health将会返回red状态，表示有主分片还没分配。
一旦每个节点的本地分片都恢复了，状态将会变成yellow，表示所有的主分片都分配了，但并不是所有副本都有分配。这就是期待的效果，毕竟分片平衡还被禁用中。

第六步：重启平衡

延后副本分配，直到所有节点都加入集群，master就可以给本地已有分片拷贝的节点分配副本了。这时所有节点都在集群中，可以安全得重启分片平衡了。

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监控这个过程

一旦_cat/health返回结果的 status列返回 green，说明所有的主分片和副本都分配完毕。