如何将正在运行的 Elasticsearch 旧实例升级到新版本？

Posted 2023-04-18

技术标签:

【中文标题】如何将正在运行的 Elasticsearch 旧实例升级到新版本？【英文标题】：How to upgrade a running Elasticsearch older instance to a newer version? 【发布时间】：2012-02-29 10:16:35 【问题描述】：

基本上我找不到解释将正在运行的 Elasticsearch 实例升级到当前版本的过程的文档或资源。

请在几种情况下帮助我：

如果我在单个服务器上运行 Elasticsearch 实例，如何我升级实例而不丢失数据？

如果我在多台服务器上运行多个 Elasticsearch 实例，如何在不丢失数据的情况下升级 Elasticsearch 实例的同时保持操作运行？

如果对此有适当的程序或解释，将极大地帮助我理解和工作。谢谢！

【问题讨论】：

【参考方案1】：

所有节点数据都存储在 elasticsearch 数据目录中。在 elasticsearch home 中默认为 data/cluster_name/nodes。所以，一般来说，只要保留数据目录，并且新版本中的配置文件与旧版本兼容，新实例应该与旧实例具有相同的数据。请注意，某些版本在release notes 中列出了特殊的附加要求。例如，从 0.18 升级到 0.19 需要对集群中的所有索引发出完全刷新。

确实没有什么好的方法可以做到这一点。节点使用不向后兼容的二进制协议进行通信。因此，如果新版本中的协议发生变化，旧节点和新节点就无法相互理解。有时可以在同一个集群中混合具有不同次要版本的节点并进行滚动升级。但是，据我了解，即使在次要版本中，节点之间的兼容性也没有明确的保证，主要版本总是需要完全重启集群。如果在整个集群重启期间停机不是一个选项，DrTech 的nice technique 可能是一个解决方案。

【讨论】：

我明白了，所以基本上在单个Elasticsearch实例的目录下，我们只是替换elasticsearch/bin和elasticsearch/lib文件夹，保留elasticsearch/data文件夹和新版本的elasticsearch实例应该自动独立工作吗？目前，如果您使用插件，还有可能很重要的插件目录。 elasticsearch 的未来版本可能会添加新目录。因此，最好将其视为将旧的 elasticsearch/data 和 elasticsearch/config 目录放入新安装中。具有替换数据和配置目录的新弹性搜索实例应自动将数据更新到新版本并开始工作。请注意，旧版本的 elasticsearch 将不再适用于更新的数据目录。感谢您指出 DrTech 的提示......所以它可以重新审视我的想法:)！【参考方案2】：

现在关于 ElasticSearch 升级的信息比以前多了很多。

以下是我升级 ElasticSearch 时的常用步骤：

备份数据：Snapshot and Restore

升级指南：Upgrading ElasticSearch

主要思想是您一次关闭 ES 集群的一个实例，升级该实例节点上的 ES 版本，然后再次启动它，以便它可以重新加入集群。

简而言之，以下是重要的步骤：

禁用分片重新分配

curl -XPUT localhost:9200/_cluster/settings -d ' “短暂的” ： “cluster.routing.allocation.enable”：“无” '

关闭实例：

curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'

在主机上安装新的 ElasticSearch 版本并启动它。

启用分片重新分配：

curl -XPUT localhost:9200/_cluster/settings -d ' “短暂的” ： “cluster.routing.allocation.enable”：“全部” '

观察集群从 yellow 状态到 green 的状态：

curl -X GET http://localhost:9200/_cat/health?v // 监控集群整体状态

curl -X GET http://localhost:9200/_cat/nodes?v // 验证新节点是否加入集群

curl -X GET http://localhost:9200/_cat/shards?v // 查看正在启动、初始化和重新定位的分片

重复下一个节点。

在排序方面，首先更新主节点，然后是数据节点，然后是负载平衡/客户端节点。

【讨论】：

您提到“在排序方面，首先更新主节点，然后是数据节点，然后是负载平衡/客户端节点。”这是不对的，正确的顺序是最好在所有其他节点之后升级集群中的主合格节点。一旦您开始升级符合主节点资格的节点，它们可能会形成一个旧版本节点无法加入的集群。如果您最后升级主节点，那么所有其他节点将不会运行旧版本，因此它们将能够加入集群。【参考方案3】：

值得一提的是，现在有关于进行此升级的文档，但它在搜索结果中的排名并不高：

Upgrade Elasticsearch

以及一个重大更改文档：

Breaking Changes

【讨论】：

【参考方案4】：

其他答案与现在存在的相比有些过时，因此这些新信息将补充升级 Elasticsearch 的较新版本，例如将 6.x 升级到 7.x，或从 5.x 升级到 6.x。 Elasticsearch 升级有两个主要选项：rolling upgrade 或 full cluster restart。

滚动升级允许一次升级一个节点，因此服务不会中断。另一方面，完整的集群重启要求每个节点都关闭、升级，然后重新启动。这意味着必须考虑升级之间的停机时间。

与几年前唯一可行的选择是快照和恢复相比，这要容易得多。

【讨论】：

【参考方案5】：

这里有两篇关于这个问题的文章，我非常喜欢！

https://www.freecodecamp.org/news/how-to-migrate-from-elasticsearch-1-7-to-6-8-with-zero-downtime/ https://blog.devartis.com/how-we-upgraded-a-10-tb-elasticsearch-cluster-from-1-7-to-6-7-466f6a33a6ca

基本上，该方法是启动一个新集群（使用您想要的最新 ElasticSearch 版本），通过更改代码以使其索引 both（旧和新的）集群并开始对新集群进行完整的重新索引。

此时，您的数据应该有两个完全同步的集群。这允许您开始将您的读取功能插入新集群，看看它是如何进行的，可能修复发出 ES 请求有关重大更改的代码（在您当前的 ES 版本和您要使用的新版本之间），轻松回滚到如果需要，旧集群。

一旦一切顺利，您就可以开始插入写入/更新功能...并最终在几周或几个月后关闭旧集群。

它非常灵活，但完全取决于您所面临的用例/时间线。主要可能的问题是：旧集群的映射是否会与新集群完全兼容？

希望对您有所帮助！祝你有美好的一天:)

【讨论】：

【参考方案6】：

如果您正在运行基于 Ubuntu 或 Debian 的 Linux，只要您不在主要版本之间进行升级，这里有一个 Ansible 脚本可以进行滚动升级。

1.3 -> 1.4.3等小版本都可以

0.8 -> 1.4.3等大版本将无法使用。

https://github.com/ekhoinc/ansible-examples/blob/master/elasticsearch-rolling-upgrade.yml

可以很容易地修改它以使用基于 RHEL 的 linux（只需更改 2 行）