3. Upgrade Elasticsearch

升级 Elasticsearch

Elasticsearch 通常可以使用滚动升级 Rolling upgrade 过程进行升级，因此升级不会中断服务。但是，您可能需要使用 Reindex 来升级 Reindex to upgrade 在旧版本中创建的索引。在 6.0 之前的主要版本之间进行升级需要完全重启群集 Full cluster restart。

当升级到新版本的 Elasticsearch 时，需要升级 Elastic Stack 中的每个产品。升级所需的步骤因所使用的产品而异。想要一个定制有关升级堆栈的更多信息的列表，请参阅升级 Elastic StackUpgrading the Elastic Stack

在升级 Elasticsearch 之前：

查看影响您应用程序的更改的重大变化(breaking changes)。
检查弃用日志(deprecation log)，看看您是否使用任何弃用的功能。
如果您使用自定义插件，请确保兼容版本可用。
升级生产群集之前，在开发环境中测试升级。
升级前备份您的数据(Back up your data)。你不能回退，除非你有你的数据备份到一个较早的版本。

下表显示何时可以执行滚动升级，什么时候需要重新索引或删除旧的索引，以及何时需要完整的群集重新启动。

升级前	升级后	支持的升级类型
5.x	5.y	滚动升级(y>x)
5.6	6.x	滚动升级
5.0-5.5	6.x	全集群重启[a]
<5.x	6.x	重建索引来升级
6.x	6.y	滚动升级(y>x)[b]

[a]在升级之前，您必须删除或重新索引在 2.x 中创建的任何索引。
[b] 从 6.0.0 之前的 GA 版本升级需要完整的群集重启。

Elasticsearch 可以读取在以前的主版本中创建的索引。旧的索引必须重建索引或删除。Elasticsearch 6.x 可以使用在 Elasticsearch 5.x 中创建的索引，但不能使用在 Elasticsearch 2.x 或之前创建的索引。Elasticsearch 5.x 可以使用在 Elasticsearch 2.x 中创建的索引，但不能使用在 1.x 或之前创建的索引。

这也适用于使用快照和还原进行备份的索引。如果索引最初是在 2.x 中创建的，即使快照是由 2.x 集群创建的，也不能恢复到 6.x 集群。

如果不兼容的索引存在，Elasticsearch 节点将无法启动。

有关如何升级旧索引的信息，请参阅 Reindex 升级 Reindex to upgrade。

滚动升级

滚动升级允许 Elasticsearch 群集一次升级一个节点，因此升级不会中断服务。一旦超过升级期限,在同一集群中运行多个版本的 Elasticsearch 是不支持的,因为无法将分片从已升级的节点复制到运行旧版本的节点。

滚动升级可以在次要版本之间执行。Elasticsearch 6.x 支持 Elasticsearch 5.6 的滚动升级。从较早的 5.x 版本升级需要完整的群集重启。您必须重新索引以从 5.x 之前的版本升级。

要执行滚动升级：

1.禁用分片分配

关闭节点时，分配过程会等待一分钟，然后才能将该节点上的分片复制到集群中的其他节点，从而导致大量浪费的 I / O 资源。在关闭节点之前，可以通过禁用分配来避免耗时的分片分配行为(racing the clock)：

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

2. 停止非必要的索引并执行同步刷新。（可选的）

虽然可以在升级过程中继续建立索引，但是如果临时停止非必要的索引并执行同步刷新，则碎片恢复速度会更快。

POST _flush/synced

执行同步刷新时，请检查响应以确保没有故障失败。由于挂起索引操作而失败的同步刷新操作在响应体中列出，尽管请求本身仍然返回 200 OK 状态。如果出现故障，请重新发出请求。

3. 关闭单个节点

如果你正在以 systemd 方式运行 Elasticsearch：

sudo systemctl stop elasticsearch.service
如果你正在以 SysV init 方式运行 Elasticsearch

sudo -i service elasticsearch stop
如果你正在守护进程的方式运行 elasticsearch

kill $(cat pid)

备注

systemd 和 Sysv 是 linux 系统下的不同的启动进程的方式,详情请参考

CentOS7 开机启动管理 systemd 简介及使用

4. 升级您关闭的节点

使用 Debian 或 RPM 软件包进行升级：

使用 rpm 或 dpkg 安装新的软件包。所有文件都安装在操作系统的适当位置，Elasticsearch 配置文件不会被覆盖。

要使用 zip 或压缩 tarball 进行升级：

a.提取 zip 或 tarball 到一个新的目录。如果你不使用外部 config 和 data 目录，这是至关重要的。

b.设置 ES_PATH_CONF 环境变量以指定外部 config 目录和 jvm.options 文件的位置。如果您没有使用外部 config 目录，请将旧的配置复制到新的安装中。

c. 设置 path.data 在 config/elasticsearch.yml 指向您的外部数据目录。如果您不使用外部 data 目录，请将旧的数据目录复制到新的安装中。

d. 设置 path.logs 在 config/elasticsearch.yml 指向要保存你的日志的位置。如果不指定此设置，则日志将存储在您将存档提取到的目录中。

![https://www.elastic.co/guide/en/elasticsearch/reference/current/images/icons/tip.png] 当你解压 ZIP 压缩包或 tar 压缩包，elasticsearch-n.n.n 目录包含 Elasticsearh config，data，logs 和 plugins 目录。
我们建议将这些目录移出 Elasticsearch 目录，以便在升级 Elasticsearch 时不会删除它们。要指定新的位置，请使用 ES_PATH_CONF 环境变量和 path.data 和 path.logs 设置。有关更多信息，请参阅重要的 Elasticsearch 配置。
在 Debian 的和 RPM 包放在这些目录中的每个操作系统的适当位置。在生产中，我们推荐使用 deb 或 rpm 包进行安装。

5. 升级任何插件

使用 elasticsearch-plugin 脚本来安装每个已安装的 Elasticsearch 插件的升级版本。升级节点时必须升级所有插件。

6. 启动升级的节点

启动新升级的节点并通过检查日志文件或提交_cat/nodes 请求确认它是否加入群集：

GET _cat/nodes

7. 重新启用分片分配

一旦节点加入集群，重新启用碎片分配以开始使用节点：

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

8.等待节点恢复

在升级下一个节点之前，等待集群完成分片分配。您可以通过提交_cat/health 请求来检查进度：

GET _cat/health

等待 status 列切换 yellow 到 green。一旦节点完成 green，所有主分片和复制分片都被分配。

在滚动升级期间，分配给运行新版本的节点的主分片不能将其副本分配给具有旧版本的节点。新版本可能具有旧版本无法理解的不同数据格式。如果不能将副本分片分配给另一个节点（群集中只有一个升级节点），则副本分片保持未分配状态并保持状态 yellow。在这种情况下，只要没有初始化或重新定位碎片，就可以继续（检查 init 和 relo 列）。一旦另一个节点升级，副本分片可以分配，状态将更改为 green。

未同步刷新的分片可能需要更长时间才能恢复。您可以通过提交_cat/recovery 请求来监视单个碎片的恢复状态：

GET _cat/recovery

如果您停止建立索引，恢复完成后立即恢复索引是安全的。

9. 重复

当节点恢复并且集群稳定时，对每个需要更新的节点重复这些步骤。

滚动升级期间，群集继续正常运行。但是，在群集中的所有节点均已升级之前，任何新功能都将被禁用或以向后兼容模式运行。一旦升级完成并且所有节点都运行新版本，新功能就可以运行。一旦发生这种情况，就无法返回到向后兼容模式下运行。运行以前的主要版本的节点将不被允许加入完全更新的集群。
升级过程中发生网络故障的情况不太可能，在将所有剩余的旧节点与群集隔离的情况下，必须使旧节点脱机，并升级它们以使其能够加入群集。

集群重启升级

完整的群集重新启动升级要求关闭群集中的所有节点，升级它们并重新启动群集。升级到 6.x 之前的主要版本时，需要完全重启群集。Elasticsearch 6.x 的支持滚动升级，从 Elasticsearch 5.6。从早期版本升级到 6.x 需要完整的群集重启。请参阅升级路径表以验证您需要执行的升级类型。

要执行完整群集重新启动升级：

1. 禁用分片分配

关闭节点时，分配过程会等待一分钟，然后才能将该节点上的分片复制到集群中的其他节点，从而导致大量浪费的 I / O。在关闭节点之前，可以通过禁用分配来避免时钟比赛：

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

2. 停止索引并执行刷新操作

执行同步刷新可加速碎片恢复。

POST _flush /同步

执行同步刷新时，请检查响应以确保没有故障。由于挂起索引操作而失败的同步刷新操作在响应主体中列出，尽管请求本身仍然返回 200 OK 状态。如果出现故障，请重新发出请求。

3. 关闭所有节点.

如果你正在以 systemd 方式运行 Elasticsearch：

sudo systemctl stop elasticsearch.service
如果你正在以 SysV init 方式运行 Elasticsearch

sudo -i service elasticsearch stop
如果你正在守护进程的方式运行 elasticsearch

kill $(cat pid)

4. 升级所有节点.

使用 Debian 或 RPM 软件包进行升级：

使用 rpm 或 dpkg 安装新的软件包。所有文件都安装在操作系统的适当位置，Elasticsearch 配置文件不会被覆盖。

要使用 zip 或压缩 tarball 进行升级：

a. 提取 zip 或 tarball 到一个新的目录。如果你不使用外部 config 和 data 目录，这是至关重要的。

b. 设置 ES_PATH_CONF 环境变量以指定外部 config 目录和 jvm.options 文件的位置。如果您没有使用外部 config 目录，请将旧的配置复制到新的安装中。

c. 设置 path.data 在 config/elasticsearch.yml 指向您的外部数据目录。如果您不使用外部 data 目录，请将旧的数据目录复制到新的安装中。

d. 设置 path.logs 在 config/elasticsearch.yml 指向要保存你的日志的位置。如果不指定此设置，则日志将存储在您将存档提取到的目录中。

当你解压 ZIP 压缩包或套餐，elasticsearch-n.n.n 目录包含 Elasticsearh config，data，logs 和 plugins 目录。
我们建议将这些目录移出 Elasticsearch 目录，以便在升级 Elasticsearch 时不会删除它们。要指定新的位置，请使用 ES_PATH_CONF 环境变量和 path.data 和 path.logs 设置。有关更多信息，请参阅重要的 Elasticsearch 配置。

在 Debian 的和 RPM 包放在这些目录中的每个操作系统的适当位置。在生产中，我们推荐使用 deb 或 rpm 包进行安装。

5. 升级所有插件.

使用 elasticsearch-plugin 脚本来安装每个已安装的 Elasticsearch 插件的升级版本。升级节点时必须升级所有插件。

6.重启每个升级后的节点.

如果您有专用的主节点，请先启动它们，然后等待它们形成一个集群并选择一个主节点，然后再继续处理数据节点。您可以通过查看日志来检查进度。

只要最少数量的主节点相互发现，它们就形成一个簇并选出一个主节点。此时，您可以使用_cat/health 和 _cat/nodes 监视加入群集的节点：

GET _cat /health

GET _cat /nodes

7. 等待所有节点加入群集并报告黄色状态。

当一个节点加入集群时，它开始恢复本地存储的任何主分片。该_cat/healthAPI 最初将报告 status 中 red，表明并非所有的初级碎片已被分配。

一旦节点恢复其本地碎片，群集 status 将切换到 yellow，指示所有主碎片已被恢复，但并不是所有副本碎片都被分配。这是可以预料的，因为你还没有重新启用分配。延迟副本的分配，直到所有节点都 yellow 允许主节点将副本分配给已具有本地分片副本的节点。

8. 重新分配。

当所有节点加入群集并恢复其主分片时，重新启用分配。

PUT _cluster / settings 
{ 
  “persistent”：{ 
    “cluster.routing.allocation.enable”：“all” 
  } 
}

一旦分配被重新启用，集群开始分配副本分片到数据节点。此时，恢复索引和搜索是安全的，但是如果您可以等到所有主分片和副本分片成功分配并且所有节点的状态为止，那么您的集群将会更快地恢复 green。

您可以使用_cat/health 和 _cat/recoveryAPI 监视进度：

GET _cat/health

GET _cat/recovery

升级前重建索引

Elasticsearch 可以读取在以前的主要版本中创建的索引。旧的指数必须重新编制索引或删除。Elasticsearch 6.x 可以使用在 Elasticsearch 5.x 中创建的索引，但不能使用在 Elasticsearch 2.x 或之前创建的索引。Elasticsearch 5.x 可以使用在 Elasticsearch 2.x 中创建的索引，但不能使用在 1.x 或之前创建的索引。

如果不兼容的索引存在，Elasticsearch 节点将无法启动。

要升级包含 2.x 中创建索引的 Elasticsearch 5.x 群集，必须在升级到 6.x 之前重新索引或删除它们。有关更多信息，请参阅 Reindex。

要升级运行 2.x 的 Elasticsearch 集群，您有两个选择：

执行完全集群重新启动升级到 5.6，重新索引 2.x 索引，然后执行滚动升级到 6.x. 如果您的 Elasticsearch 2.x 集群包含在 2.x 之前创建的索引，则必须删除或重新索引它们，然后再升级到 5.6。有关从 2.x 升级到 5.6 的更多信息，请参阅 Elasticsearch 5.6 参考中的升级 Elasticsearch。
创建一个新的 6.x 集群，并从远程重建索引，直接从 2.x 集群导入索引。

要升级 Elasticsearch 1.x 群集，您有两个选择：

执行完全集群重新启动升级到 Elasticsearch 2.4.x 并重新索引或删除 1.x 索引。然后，执行完全集群重新启动升级到 5.6，重新索引或删除 2.x 索引。最后，滚动升级到 6.x. 有关从 1.x 升级到 2.4 的更多信息，请参阅 Elasticsearch 2.4 参考中的升级 Elasticsearch。有关从 2.4 升级到 5.6 的更多信息，请参阅 Elasticsearch 5.6 参考中的升级 Elasticsearch。
创建一个新的 6.x 集群，并从远程重新索引，直接从 1.x 集群导入索引。

升级基于时间的索引
如果您使用基于时间的索引，则可能不需要将 5.x 之前的索引推到 6.x. 随着时间流逝，基于时间的索引的数据通常变得不那么有用，并且随着时间超过保留期而被删除。
除非您的保留期限非常长，否则您可以等待升级到 6.x，直到 5.x 之前的所有索引都被删除。

重建索引

要使用 reindexAPI 手动重新索引旧索引，请执行以下操作：

创建一个新的索引，并复制旧索引的映射和设置。
将 refresh_interval 要-1 和 number_of_replicas 以 0 高效重建索引。
使用 reindex API 将旧索引中的所有文档重新索引到新索引中。
重置 refresh_interval 并 number_of_replicas 在旧索引使用的值。
等待索引状态更改为 green。
在一个更新别名请求中：
- 删除旧的索引。
- 将具有旧索引名称的别名添加到新索引。
- 将旧索引中存在的任何别名添加到新索引。

迁移协助和升级工具
X-Pack 5.6 提供了迁移帮助和升级工具，可以简化重新索引和升级到 6.x. 这些工具免费提供 X-Pack 试用版和 Basic 许可证，您可以使用它们升级 X-Pack 是否是 Elastic Stack 的常规部分。有关更多信息，请参阅 http://www.elastic.co/guide/en/elastic-stack/6.0/upgrading-elastic-stack.html。

从远程集群中重建索引

您可以使用远程重建索引将索引从旧集群迁移到新的 6.x 集群。这使您可以从 5.6 之前的群集移到 6.x 而不会中断服务。

Elasticsearch 提供向后兼容性支持，使以前的主要版本的索引能够升级到当前的主要版本。跳过主要版本意味着您必须自己解决任何向后兼容性问题。

迁移您的索引：

在旧集群旁边设置一个新的 6.x 集群。通过将您的旧集群添加到 reindex.remote.whitelistin elasticsearch.yml：使其能够访问您的旧集群

reindex.remote.whitelist：oldhost：9200

新集群不必开始全面扩展。在迁移索引并将负载转移到新集群时，可以将节点添加到新集群，并从旧集群中删除节点。

对于您需要迁移到 6.x 群集的每个索引：
- 使用适当的映射和设置在 6.x 中创建一个新的索引。设置 refresh_interval 于-1 和设置 number_of_replicas，以 0 更快的重建索引。
- 从远程重建索引，将旧索引中的文档拖入新的 6.x 索引：
```
  POST _reindex
    {
      "source": {
        "remote": {
          "host": "http://oldhost:9200",
          "username": "user",
          "password": "pass"
        },
        "index": "source",
        "query": {
          "match": {
            "test": "data"
          }
        }
      },
      "dest": {
        "index": "dest"
      }
    }  
```
如果你通过设置在后台运行重新索引工作 wait_for_completion 来 false，重新索引请求返回一个 task_id 你可以用它来监视与重新索引工作的进度任务 API： GET _tasks/TASK_ID。
- 当 reindex 作业完成后，将 refresh_interval 和 number_of_replicas 设置为所需的值（默认设置是 30s 和 1）。
- 一旦复制完成并且新索引的状态为 green，则可以删除旧的索引。