• 次要版本之间
• 从 5.6 到 6.8
• 从 6.8 到 7.6.2
• 从 7.6.0 到 7.6.2 之后的任何版本

Elasticsearch 可以读取在以前的主要版本中创建的索引。如果在 5.x 或更早版本中创建了索引，则必须在升级到 7.6.2 之前重建索引或删除它们。如果存在不兼容的索引，Elasticsearch 节点将无法启动。5.x 或更早版本索引的快照无法恢复到 7.x 集群，即使它们是由 6.x 集群创建的。有关升级旧索引的信息，请参阅重新索引以升级。

升级到新版本的 Elasticsearch 时，需要升级 Elastic Stack 中的每个产品。有关更多信息，请参阅 Elastic Stack 安装和升级指南。

滚动升级

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

强烈建议在升级时将集群节点分为以下两组，并按以下顺序升级组：

可以按任何顺序升级每个组中的节点。

按此顺序升级节点可确保不符合主资格的节点始终运行至少与符合主资格的节点一样新的版本。较新的节点总是可以加入具有较旧 master 的集群，但较旧的节点不能总是加入具有较新 master 的集群。通过最后升级符合主节点的节点，可以确保所有不符合主节点的节点都能够加入集群，无论主节点是否已升级。如果在不适合主节点的节点之前升级任何符合主节点的节点，则存在较旧的节点将离开集群并且在升级之前无法重新加入的风险。

支持滚动升级的版本：

从 6.7 或更早版本直接升级到 7.6.2 需要 完全重启集群。

准备升级

在开始升级之前仔细准备非常重要。开始将集群升级到 7.6.2 版后，必须完成升级。一旦集群包含版本 7.6.2 的节点，它就可能对其内部状态进行无法恢复的更改。如果无法完成升级，则应丢弃部分升级的集群，部署升级前版本的空集群，并从快照恢复其内容。

在开始将集群升级到 7.6.2 版之前，应该执行以下操作。

升级集群

要执行滚动升级到 7.6.2：

4. 在config/elasticsearch.yml中设置path.logs以指向要存储日志的位置。如果不指定此设置，日志将存储在将存档解压缩到的目录中。

GET _cat/nodes

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

GET _cat/health?v

GET /_cat/health?v

GET /_cat/nodes?h=ip,name,version&v

POST _ml/set_upgrade_mode?enabled=false

1. 检查弃用日志以查看是否正在使用任何弃用的功能并相应地更新您的代码。
2. 查看重大更改并对版本 7.6.2 的代码和配置进行任何必要的更改。
3. 如果使用任何插件，请确保每个插件与 Elasticsearch 版本 7.6.2 兼容的版本。
4. 在升级生产集群之前，在隔离环境中测试升级。
5. 通过拍摄快照来备份您的数据！

1. 禁用分片分配。

   当关闭一个节点时，分配过程会等待 index.unassigned.node_left.delayed_timeout（默认情况下，一分钟），然后才开始将该节点上的分片复制到集群中的其他节点，这可能涉及大量 I/O。由于节点即将重新启动，因此不需要此 I/O。可以通过在关闭节点之前禁用副本分配来避免时钟竞争 ：

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

2. 停止索引并执行同步刷新。

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

   POST _flush/synced

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

   请注意，同步刷新已在7.x版本标记为过期的，将在 8.0 中删除此功能。在 Elasticsearch 7.6 或更高版本上，刷新与同步刷新具有相同的效果。

3. 暂时停止与活动机器学习作业和数据馈送相关的任务。（可选的）

   如果机器学习索引是在 6.x 之前创建的，必须 重新索引索引。

   如果机器学习索引是在 6.x 中创建的，可以：

   • 在升级期间保持机器学习作业运行。当关闭机器学习节点时，其作业会自动移动到另一个节点并恢复模型状态。此选项使作业能够在升级期间继续运行，但会增加集群的负载。

   • 使用set upgrade mode API暂时停止与您器学习作业和数据馈送相关的任务，并防止打开新作业 ：

     POST _ml/set_upgrade_mode?enabled=true

     当禁用升级模式时，作业将恢复到自动保存的最后一个模型状态。此选项避免了在升级期间管理活动作业的开销，并且比显式停止数据馈送和关闭作业更快。

   • 停止所有数据馈送并关闭所有作业。此选项保存关闭时的模型状态。升级后重新打开作业时，它们使用完全相同的模型。但是，保存最新模型状态比使用升级模式需要更长的时间，尤其是当有大量作业或具有大型模型状态的作业时。

4. 关闭所有节点。

   • systemd运行 Elasticsearch：

     sudo systemctl stop elasticsearch.service

   • SysV init运行 Elasticsearch：

     sudo -i service elasticsearch stop

   • Elasticsearch 作为守护进程运行：

     kill $(cat pid)

5. 升级所有节点。

   重要

   如果从 6.2 或更早版本升级并使用 X-Pack，请在升级前运行bin/elasticsearch-plugin remove x-pack以删除 X-Pack 插件。X-Pack 功能现在包含在默认发行版中，不再单独安装。如果存在 X-Pack 插件，则升级后节点将不会启动。需要降级、删除插件并重新应用升级。

   要使用Debian或RPM软件包升级：

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

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

   1. 将 zip 或 tarball 解压缩到新目录。如果不使用外部config和data目录，这一点至关重要。
   2. 设置ES_PATH_CONF环境变量以指定外部config目录和jvm.options文件的位置。如果不使用外部config目录，请将旧配置复制到新安装的目录中。

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

      重要

      如果使用监控功能，请在升级 Elasticsearch 时重新使用数据目录。监控使用持久性 UUID 标识唯一的 Elasticsearch 节点，该 UUID 存储在数据目录中。

   4. 在config/elasticsearch.yml中设置path.logs以指向要存储日志的位置。如果不指定此设置，日志将存储在存档解压缩到的目录中。

   TIPS

   当解压ZIP压缩包或tarball，elasticsearch-n.n.n 目录会包含Elasticsearch config，data和logs目录。

   建议将这些目录移出 Elasticsearch 目录，以便在升级 Elasticsearch 时不会删除它们。要指定新位置，请使用ES_PATH_CONF环境变量和path.data和path.logs设置。有关更多信息，请参阅重要的 Elasticsearch 配置。

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

1. 升级任何插件。

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

2. 如果使用 Elasticsearch 安全功能来定义领域，请确保领域设置是最新的。领域设置的格式在 7.0 版中发生了变化，特别是领域类型的位置发生了变化。请参阅 领域设置。

3. 启动每个升级的节点。

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

   一旦有足够多的符合主节点条件的节点相互发现，它们就会形成一个集群并选举一个主节点。此时，可以使用 _cat/health和_cat/nodes监视加入集群的节点：

   GET _cat/healthGET _cat/nodes

   该status列中返回通过_cat/health获取的每个节点在集群中的健康状态：red，yellow，或green。

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

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

   一旦一个节点恢复了它的本地分片，集群status就会切换到 yellow，表明所有的主分片都已经恢复，但不是所有的副本分片都被分配了。这是意料之中的，因为尚未重新启用分配。延迟分配副本直到所有节点都yellow后，主节点才将副本分配给已经具有本地分片副本的节点。

5. 重新启用分配。

   当所有节点都加入集群并恢复它们的主分片后，通过恢复cluster.routing.allocation.enable到默认值来重新启用分配：

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

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

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

   GET _cat/healthGET _cat/recovery

6. 重新启动机器学习作业。

   如果暂时停止了与机器学习作业关联的任务，请使用set upgrade mode API将它们返回到活动状态：

   POST _ml/set_upgrade_mode?enabled=false

   如果在升级前关闭了所有机器学习作业，请打开作业并从 Kibana 启动数据馈送，或者使用打开的作业和启动数据馈送API。

升级前重新索引

警告

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

Elasticsearch 不支持跨主要版本的向前兼容性。例如，不能从 7.x 集群重新索引到 6.x 集群。

如果使用机器学习功能并从 6.5 或更早版本的集群迁移索引，则作业和数据馈送配置信息不会存储在索引中。必须在新集群中重新创建机器学习作业。如果从 6.6 或更高版本的集群迁移，最好暂时停止与机器学习作业和数据馈送相关的任务，以防止在不同的时间重新索引的不同机器学习索引之间出现不一致。使用 设置升级模式 API或 停止所有数据馈送并关闭所有机器学习作业。

1. 设置新的7.6.2集群，在elasticsearch.yml中添加现有群集到 reindex.remote.whitelist属性。

   reindex.remote.whitelist: oldhost:9200

   NOTE

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

2. 对于需要迁移到新集群的每个索引：

   1. 使用适当的映射和设置创建索引。设置 refresh_interval为-1，设置number_of_replicas为0，以更快的重新索引。

   2. 使用reindexAPI将远程索引中的文档拉取到新的 7.6.2 索引中：

      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。

   3. 重新索引作业完成后，将refresh_interval和 number_of_replicas设置为所需的值（默认设置为 30s和1）。
   4. 重新索引完成并且新索引的状态为green后，可以删除旧索引。