不是所有版本的Elasticsearch都可以直接升级到最新版本，跨大版本升级需要先升级到中间版本再升级到目标版本，下面是升级时的版本要求

升级前的版本	升级到的版本	升级方式
6.8和7.0–7.4	7.5.1	直接滚动升级
5.6和6.0～6.7	7.5.1	先滚动升级到6.8再滚动升级到7.5.1
5.0～5.5	7.5.1	先滚动升级到5.6再滚动升级到6.8最后滚动升级到7.5.1

Elasticsearch可以读取在先前的主要版本中创建的索引。如果您有在5.x或更早版本中创建的索引，则在升级到7.5.1之前必须重新索引或删除它们。如果存在不兼容的索引，Elasticsearch节点将无法启动。5.x或更早版本的索引快照无法还原到7.x群集，即使它们是由6.x群集创建的也是如此。重建索引的步骤在专栏其他文章中有详细讲解

注意，如果存在elastic家族中其他成员（比如kibana）依赖ES的，也需要一并升级

滚动升级

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

最好在所有其他节点之后升级群集中符合主机要求的节点。一旦开始升级符合资格的主节点，它们可能会形成一个群集，旧版本的节点无法加入。如果您最后升级了符合主机资格的节点，则所有其他节点将不会运行旧版本，因此它们将能够加入集群。

支持的滚动升级：

• 次要版本之间
• 从5.6到6.8
• 从6.8到7.5.1
• 从6.7或更早版本直接升级到7.5.1需要 完全重启群集。

准备升级

在开始升级之前，请务必做好准备。一旦开始将群集升级到版本7.5.1，就必须完成升级。群集包含版本7.5.1的节点后，它可能会对其无法还原的内部状态进行更改。如果无法完成升级，则应丢弃部分升级的群集，在升级之前部署该版本的空群集，然后从快照还原其内容。

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

1. 检查弃用日志，以查看您是否正在使用任何不赞成使用的功能，并相应地更新代码。
2. 查看重大更改，并对版本7.5.1的代码和配置进行必要的更改。
3. 如果使用任何插件，请确保每个插件的版本都与Elasticsearch 7.5.1版兼容。
4. 在升级生产群集之前，请在隔离的环境中测试升级。
5. 通过快照备份数据！
6. 模拟线上的版本和索引数据在本地模拟升级并测试业务是否正常
7. 准备好升级所用的安装包和插件提前部署到需要升级的机器各节点上（安装包比较大,需要提前上传到目标机器上，加速整个升级过程）

升级集群

1. 禁用主分片分配

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

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

如果有业务写入，最好在升级过程中暂停写入，如果写入量很大，需要在夜间执行，避免升级过程中翻车导致业务不可用，特别是在索引无副本的情况下，升级过程会导致索引数据写入失败而造成数据丢失

升级和重启集群前手动刷新是必要的，以避免分片恢复的时间过长，特别是集群在没有副本的情况下

POST _flush/synced

如果失败，请重新发起请求

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

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

• 在升级期间让机器学习作业保持运行状态。当您关闭机器学习节点时，其工作会自动移至另一个节点并恢复模型状态。此选项使您的作业可以在升级期间继续运行，但会增加群集的负载。
• 通过使用设置的升级模式API暂时停止与您的机器学习作业和数据馈送相关的任务，并阻止新作业打开：

POST _ml/set_upgrade_mode?enabled=true

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

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

4. 关闭单个节点。

sudo systemctl stop elasticsearch.service
或者kill 掉ES进程的pid

5. 升级关闭的节点

1. 将zip或tar包解压缩到新目录。如果你不使用外部config和data目录这是至关重要。
2. 设置ES_PATH_CONF环境变量以指定外部config目录和jvm.options文件的位置。如果您不使用外部config目录，则将	旧配置复制到新安装中（注意并不是所有配置项都兼容，在升级前本地测试模拟阶段需要验证）
3. 在config/elasticsearch.yml中设置path.data以指向外部数据目录。如果不使用外部数据目录，请将旧数据目录复制到新安装数据目录的对应目录中，特别需要注意保持与原目录结构一致，如果不涉及迁移数据到新机器，升级后的path.data直接跟旧版本配置保持一致也可以。
4. 在config/elasticsearch.yml中设置path.logs以指向要存储日志的位置。如果未指定此设置，则日志将存储在提取存档文件的目录中。
5. 注意：执行滚动升级时，应保持cluster.initial_master_nodes未设置。每个升级节点都加入现有的集群，因此不需要群集引导。必须在每个节点上配置 either discovery.seed_hosts 或 discovery.seed_providers。
6.  升级所有插件。升级前准备的安装包中应该包含对应升级后的插件
7. 如果使用了xpack安全功能,需要确认配置是否更新，这些在本地测试模拟中需要验证

6. 启动新升级的节点

通过检查日志文件或提交_cat/nodes请求来确认它已加入集群：

	GET _cat/nodes

7. 重新启用分片分配

节点加入集群后，删除cluster.routing.allocation.enable 设置以启用分片分配并开始使用该节点：

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

8. 等待节点恢复

在升级下一个节点之前，请等待集群完成分片分配。您可以通过提交_cat/health请求来检查进度,直到集群恢复green,这个过程根据分片数量的多少，需要消耗一定的时间

GET _cat/health?v

重要：

在滚动升级期间，不能将分配给运行新版本的节点的主分片的副本分配给具有旧版本的节点。新版本可能具有旧版本无法理解的其他数据格式。

如果无法将副本分片分配给另一个节点（集群中只有一个升级的节点），则副本分片将保持未分配状态，并且状态保持yellow不变。

在这种情况下，您可以在没有初始化或重新定位分片的情况下继续操作（检查init和relo列）。

升级另一个节点后，便可以分配副本，并且状态将更改为green。

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

GET _cat/recovery

9.其他每个节点重复４～８步骤逐个重复操作即可

需要注意的是务必等集群green后再操作下一个节点，莫要心急

10.全部节点升级完成后，重新启动机器学习作业

POST _ml/set_upgrade_mode?enabled=false

重要：

在滚动升级期间，群集继续正常运行。但是，在升级群集中的所有节点之前，任何新功能都将被禁用或以向后兼容模式运行。一旦升级完成并且所有节点都在运行新版本，新功能就可以运行。一旦发生这种情况，就没有办法返回到向后兼容模式。运行以前主要版本的节点将不允许加入完全更新的群集。

如果在升级过程中出现网络故障，将所有剩余的旧节点与群集隔离，则必须使旧节点脱机并进行升级，以使它们能够加入群集。

如果在升级过程中同时停止一半或更多符合主节点条件的节点，则群集将不可用，这意味着升级不再是滚动升级。如果发生这种情况，您应该升级并重新启动所有停止的符合主节点条件的节点，以允许群集再次形成，就像执行全群集重启升级一样。可能还需要升级所有剩余的旧节点，然后才能在重新形成群集后加入群集。

如果不支持滚动升级的版本只能通过reindex的方式重建索引到目标集群

如果升级前后使用相同的机器需要保证机器内存，网络，IO,和cpu资源足够,如果数据是TB级别请慎重操作
具体步骤已在其他文章中详细讲解过，这里就不再详细赘述，需要提醒的是，这种方式也需要确保目标集群中索引模板，mapping,插件等跟升级前的集群一一对应，插件改升级的需要升级，索引模板，mapping需要跟之前集群保持一致，reindex期间集群资源消耗严重，需要确保机器资源充足，reindex期间业务写入需要关闭