ElasticSearch从入门到放弃（二） — 升级Elasticsearch【基于官方文档7.5】

点击查看原文（包含源码和图片）：http://note.youdao.com/noteshared=dccd8841b78dfc624bcb581c9b4881b0&sub=5A575F09B8744649B94B79A34E81E219

 

Elasticsearch通常可以使用Rolling升级进行升级，因此升级不会中断服务。 哪些版本支持滚动升级：

 

• 小版本之间
• 从5.6-6.8
• 从6.8-7.1.1

 

Elasticsearch可以读取在前一个主要版本中创建的索引。如果在5中创建了索引。在升级到7.1.1之前，您必须重新索引或删除它们。如果存在不兼容的索引，则Elasticsearch节点将无法启动。即使它们是由6.x集群创建的，5.x或更早索引的快照也无法还原到7.x群集。

升级到新版本的Elasticsearch时，需要升级Elastic Stack中的每个产品。

从6.7或者更早的版本直接升级到7.1.1，你必须关闭集群，安装7.1.1，并且重启。

 

1.预升级

升级Elasticsearch之前：

 

检查弃用日志，查看是否使用了任何弃用特性，并相应地更新代码。默认情况下，当日志级别设置为WARN时，会记录弃用警告。

查看重大更改，对7.1.1的代码和配置进行任何必要的更改。

如果您使用自定义插件，请确保兼容版本可用。

在升级生产群集之前，最好在开发环境中测试升级。

备份您的数据！ 您必须拥有数据快照才能回滚到早期版本。

 

2.滚动升级

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

滚动升级支持：

 

• 小版本之间
• 从5.6-6.8
• 从6.8-7.1.1

 

从6.7或更早版本直接升级到7.1.1 需要重新启动完整群集。

 

3.要执行从6.8到7.1.1的滚动升级：

 

3.1 禁用分片分配

当你关闭一个节点，在开始将该节点上的分片复制到集群中的其他节点之前，分配进程会等待index.unassigned.node_left.delayed_timeout（默认情况下为1分钟），这可能涉及大量I / O。由于节点很快将重新启动，因此无需执行此I/O操作，您可以通过在关闭节点之前禁用副本分配：

curl -X PUT “localhost:9200/_cluster/settings” -H ‘Content-Type: application/json’ -d’ { “persistent”: { “cluster.routing.allocation.enable”: “primaries” } }

 

3.2 停止没必要的索引并且执行同步刷新。 （可选的）

在升级过程中可以继续索引，如果停止没必要的索引并且执行同步刷新，那么分片会恢复的快的多。

curl -X POST “localhost:9200/_flush/synced”

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

 

 

3.3 暂时停止与活动机器学习作业和datafeeds相关的任务。(可选)

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

如果你在6.x中版本中创建了机器学习索引，你可以：

• 让您的机器学习任务在升级期间运行。当您关闭一个机器学习节点时，它的作业将自动转移到另一个节点并恢复模型状态。此选项允许任务在升级期间继续运行，但会增加集群的负载。

 

 

• 暂时停止与计算机学习作业和datafeeds相关的任务，并使用设置的升级模式API禁止打开新任务：

curl -X POST “localhost:9200/_ml/set_upgrade_modenabled=true”

当你禁用了升级模式，使用自动保存的最后一个模型状态恢复作业。此选项避免了在升级期间管

理活动作业的开销，并且比显式地停止datafeed和关闭作业要快。

 

 

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

 

3.4 关闭一个节点

• 如果你使用systemd运行Elasticsearch可以这样来关闭：

sudo systemctl stop elasticsearch.service

 

• 如果你使用SysV init运行Elasticsearch可以这样来关闭：

sudo -i service elasticsearch stop

 

• 如果你使用守护进程运行Elasticsearch可以这样来关闭：

kill $(cat pid)

 

3.5 升级已关闭的节点

（1）使用Depain或者RPM包升级：

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

 

（2）使用zip文件或者tar文件升级：

• 解压到一个目录，如果您不使用外部配置和数据目录，这是非常关键的。

 

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

 

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

如果使用监视特性，则在升级Elasticsearch时重用数据目录。monitor使用存储在data目录中的持 久UUID标识惟一的Elasticsearch节点。

 

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

当您解压缩zip或tar包时，elasticsearch-n.n.n目录包含Elasticsearchconfg,logs,data和plugin目录。 我们建议将这些目录移出Elasticsearch目录，以便在升级Elasticsearch时不会删除它们。 要指定新位置，请使用ES_PATH_CONF环境变量以及path.data和path.logs设置。 有关更多信息，请参阅重要的Elasticsearch配置。 Debian和RPM软件包将这些目录放在每个操作系统的适当位置。 在生产中，我们建议使用deb或rpm软件包进行安装。

 

3.6 升级插件

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

 

3.7 如果使用Elasticsearch安全功能来定义域，请验证您的域设置是否是最新的。 域设置的格式在7.0版中已更改，特别是域类型的位置已更改

 

3.8 开始升级你的节点

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

curl -X GET “localhost:9200/_cat/nodes”

 

3.9 启用分片分配

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

curl -X PUT “localhost:9200/_cluster/settings” -H ‘Content-Type: application/json’ -d’ { “persistent”: { “cluster.routing.allocation.enable”: null } }

 

3.10 等待节点恢复

请等待集群分片分配完成，再升级下一个节点，你可以通过_cat/health请求来检查进度：

curl -X GET “localhost:9200/_cat/health”

 

等待status从黄色切换为绿色。 绿色标识已经分配完成。

在滚动升级期间，新版本的主分片不能分配给旧版本节点。新版本的数据格式和旧版本的数据格式可能不兼容。 如果无法将复制碎片分配给另一个节点(集群中只有一个升级的节点)，则复制碎片将保持未分配，状态保持黄色。 在这种情况下，您可以在没有初始化或重定位分片时继续（检查init和relo列）。 一旦升级了另一个节点，就可以分配副本并且状态将变为绿色。

 

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

curl -X GET “localhost:9200/_cat/recovery”

 

如果您停止索引，可以在恢复完成后立即恢复索引。

 

3.11 重复

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

 

3.12 重启机器学习工作

如果您暂时停止与计算机学习作业关联的任务，请使用set upgrade mode API将它们恢复为活动状态：

curl -X POST “localhost:9200/_ml/set_upgrade_modenabled=false”

 

如果您在升级之前关闭了所有机器学习作业，那么打开这些作业并从Kibana或使用打开的作业启动datafeeds并启动datafeeds api。

 

在滚动升级期间，群集继续正常运行。 但是，任何新功能都将被禁用或以向后兼容模式运行， 直到群集中的所有节点都升级为止。 升级完成且所有节点都运行新版本后，新功能即可运行。 一旦发生这种情况，就无法返回以向后兼容模式运行。 运行先前主要版本的节点将不被允许 加入完全更新的群集。 如果在升级过程中 络出现故障，将所有剩余的旧节点与群集隔离，则必须使旧节点脱机并升级 它们以使其能够加入群集。 在升级期间，如果一半或者一半以上的主资格节点不可用，则群集将变为不可用， 这意味着升级不再是滚动升级。如果发生这种情况，您应升级并重新启动所有已停止符合主节点 资格的节点，再次形成群集，就像执行完全群集重新启动升级一样。可能还需要升级所有剩余的 旧节点，在重新形成后加入群集。 同样，如果运行仅包含一个主节点的测试/开发环境，则应最后升级主节点。重新启动单个主节 点会强制重组群集。新群集最初只有升级后的主节点，重组后，旧节点加入集群时会被拒绝。 已升级的节点将成功重新加入集群。

 

 

4.完整集群升级

要从版本6.0-6.7直接升级到Elasticsearch 7.1.1，必须关闭群集中的所有节点，将每个节点升级到7.1.1，然后重新启动群集。

如果运行的是6.0之前的版本，则将其升级到6.8并重新索引旧索引， 或者从远程调出一个新的7.1.1集群并重新索引。

 

要执行完整集群升级到7.1.1，参考下面的步骤：

 

4.1禁用分片分配

当你关闭一个节点，在开始将该节点上的分片复制到集群中的其他节点之前，分配进程会等待index.unassigned.node_left.delayed_timeout（默认情况下为1分钟），这可能涉及大量I / O。由于节点很快将重新启动，因此无需执行此I/O操作，您可以通过在关闭节点之前禁用副本分配：

curl -X PUT “localhost:9200/_cluster/settings” -H ‘Content-Type: application/json’ -d’ { “persistent”: { “cluster.routing.allocation.enable”: “primaries” } }

 

4.2 停止没必要的索引并且执行同步刷新

在升级过程中可以继续索引，如果停止没必要的索引并且执行同步刷新，那么分片会恢复的快的多。

curl -X POST “localhost:9200/_flush/synced”

 

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

 

 

4.3 暂时停止与活动机器学习作业和datafeeds相关的任务。

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

如果你在6.x中版本中创建了机器学习索引，你可以：

 

• 让您的机器学习任务在升级期间运行。当您关闭一个机器学习节点时，它的作业将自动转移到另一个节点并恢复模型状态。此选项允许任务在升级期间继续运行，但会增加集群的负载。

 

 

• 暂时停止与计算机学习作业和datafeeds相关的任务，并使用设置的升级模式API禁止打开新任务：

curl -X POST “localhost:9200/_ml/set_upgrade_modenabled=true”

 

当你禁用了升级模式，使用自动保存的最后一个模型状态恢复作业。此选项避免了在升级期间管

理活动作业的开销，并且比显式地停止datafeed和关闭作业要快。

 

 

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

 

 

4.4 关闭所有节点

 

• 如果你使用systemd运行Elasticsearch可以这样来关闭：

sudo systemctl stop elasticsearch.service

 

• 如果你使用SysV init运行Elasticsearch可以这样来关闭：

sudo -i service elasticsearch stop

 

• 如果你使用守护进程运行Elasticsearch可以这样来关闭：

kill $(cat pid)

 

 

4.5 升级所有节点

如果你的版本是6.2或之前版本，并且安装了X-pack插件（6.2之前的是X-pack是以插件形式存在），请在升级之前运行bin / elasticsearch-plugin remove x-pack以删除X-Pack插件。 X-Pack功能现在包含在默认发行版中，不再单独安装。 如果（6.2或之前）升级之前没卸载X-Pack插件，则升级后节点将无法启动。 您需要降级，删除插件，然后重新应用升级。

 

• 使用Depain或者RPM包升级：

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

使用zip文件或者tar文件升级：

 

• 解压到一个目录，如果您不使用外部配置和数据目录，这是非常关键的。

 

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

 

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

如果使用监视特性，则在升级Elasticsearch时重用数据目录。monitor使用存储在data目录中的持久UUID标识惟一的Elasticsearch节点。

 

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

当您解压缩zip或tar包时，elasticsearch-n.n.n目录包含Elasticsearchconfg,logs,data和plugin目录。

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

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

 

 

4.6 升级插件

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

 

4.7 如果使用Elasticsearch安全功能来定义域，请验证您的域设置是否是最新的。 域设置的格式在7.0版中已更改，特别是域类型的位置已更改。 请参阅域设置。

 

4.8 启动每个升级完成的节点

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

 

如果从6.x群集升级，则必须通过设置cluster.initial_master_nodes设置来配置群集引导。

 

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

curl -X GET “localhost:9200/_cat/health” curl -X GET “localhost:9200/_cat/nodes”

 

 

4.9 等待所有节点加入集群并 告状态为黄色

当节点加入集群时，它开始恢复本地存储的所有主分片。_cat/health 最初 告状态为红色，表示没有分配所有主分片。

 

一旦一个节点恢复了它的本地分片，集群状态就切换到黄色，这表明所有主分片都已恢复，但并没有分配所有复制分片。这是预期的，因为您还没有重新启用分配。所有节点状态都变为黄色时，再开始副本的分配，主节点的副本允许被分配到已经具有副本的节点中。

 

 

4.10 启用分配

当所有节点都已加入群集并恢复其主分片时，请通过将cluster.routing.allocation.enable恢复为其默认值来重新启用分配：

curl -X PUT “localhost:9200/_cluster/settings” -H ‘Content-Type: application/json’ -d’ { “persistent”: { “cluster.routing.allocation.enable”: null } }

 

一旦重新启用分配，集群就开始向数据节点分配副本分片。此时，恢复索引和搜索是安全的，但是如果您能够等到成功分配了所有主分片和副本分片，并且所有节点的状态都是绿色的，那么您的集群将恢复得更快。

你可以通过_cat/health和_cat/recoveryAPI来检查进度：

curl -X GET “localhost:9200/_cat/health” curl -X GET “localhost:9200/_cat/recovery”

 

4.11 重启机器学习工作

如果您暂时停止与计算机学习作业关联的任务，请使用set upgrade mode API将它们恢复为活动状态：

curl -X POST “localhost:9200/_ml/set_upgrade_modenabled=false”

 

如果您在升级之前关闭了所有机器学习作业，那么打开这些作业并从Kibana或使用打开的作业启动datafeeds并启动datafeeds api。

 

5. 升级前重新索引

Elasticsearch可以读取在前一个主要版本中创建的索引。如果在5中创建了索引。在升级到7.1.1之前，您必须重新索引或删除它们。如果存在不相容的索引，则Elasticsearch节点将无法启动。 即使它们是由6.x群集创建的，5.x或更早索引的快照也无法还原到7.x群集。

 

这个限制也适用于Kibana和X-Pack特性使用的内部索引。因此，在使用7.1.1中的Kibana和X-Pack特性之前，必须确保内部索引具有兼容的索引结构。

 

有两种方法可以重建旧索引：

 

（1）升级前在老版本上重建索引。

（2）创建一个新的7.1.1集群并从远程重新索引。这能够重新索引驻留在运行任何版本的Elasticsearch的集群上的索引。（兼容性强）

 

5.1 重建索引

您可以使用Kibana 6.7中的升级助手自动把5.x的索引转发到7.1.1。

 

手动重建索引：

• 创建具有7.x兼容映射的索引。

 

• 将refresh_interval设置为-1，将number_of_replicas设置为0以进行有效的重建索引。

 

• 使用reindex API将5.x索引中的文档复制到新索引中。 在重新索引期间，可以使用脚本对文档数据和元数据执行任何必要的修改。

 

• 将refresh_interval和number_of_replicas重置为旧索引中使用的值。

 

• 等待索引状态改变为绿色。

 

• 在单个更新别名请求中：

删除旧索引。

将具有旧索引名的别名添加到新索引中。

把旧索引上已存在的别名添加到新索引。

 

• 如果使用机器学习功能并且机器学习索引是在6.x之前创建的，则必须暂时停止与机器学习作业和datafeed相关的任务，防止在重新索引期间打开新作业。 使用set upgrade mode API或停止所有datafeed并关闭所有计算机学习作业。

如果您使用Elasticsearch安全功能，则在重新索引.security *内部索引之前，最好在文件域中创建

临时超级用户帐户。

 

a. 在单个节点上，将临时超级用户帐户添加到文件域。 例如，运行elasticsearch-users useradd命令：

bin/elasticsearch-users useradd <user_name> -p <password> -r superuser

 

b. 重新索引.security *索引时使用这些凭据。 也就是说，使用它们登录Kibana并运行升级助手或调用reindex API。 您可以使用常规管理凭据重新索引其他内部索引。

c. 从文件域中删除临时超级用户帐户。 例如，运行elasticsearch-users userdel命令：

bin/elasticsearch-users userdel <user_name>

 

 

6. 从远程集群重建索引

您可以使用来自远程的reindex将索引从旧集群迁移到7.1.1集群。 这使您可以从6.7之前的集群迁移到7.1.1而不会中断服务。

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

如果使用机器学习特性，并且要从6.5或更早的集群迁移索引，则作业和数据流配置信息不会存储在索引中。您必须在新的集群中重新创建机器学习作业。如果要从6.6或更高版本的集群迁移，最好暂时停止与机器学习作业和数据存储相关的任务，以防止微小时差重新索引的不同机器学习索引之间的不一致性。使用set upgrade mode API或停止所有数据存储并关闭所有机器学习作业。

 

6.1 迁移索引：

(1) 设置新的7.1.1集群，并将现有集群添加到elasticsearch.yml中的reindex.remote.whitelist。

reindex.remote.whitelist: oldhost:9200

 

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

 

 

(2) 对于需要迁移到新集群的索引：

• 创建索引适当的映射和设置。 将refresh_interval设置为-1并将number_of_replicas设置为0以便更快地重建索引。

 

• 使用reindexAPI将远程索引中的文档提取到新的7.1.1索引中：

curl -X POST “localhost:9200/_reindex” -H ‘Content-Type: application/json’ -d’ { “source”: { “remote”: { “host”: “http://oldhost:9200”, “username”: “user”, “password”: “pass” }, “index”: “source”, “query”: { “match”: { “test”: “data” } } }, “dest”: { “index”: “dest” } }

 

如果通过将wait_for_completion设置为false在后台运行重建索引作业，则reindex请求将返回一个task_id（任务id，用来查看任务完成进度），您可以使用该taskAPI监视reindex作业的进度：GET _tasks / TASK_ID

 

• reindex作业完成后，将refresh_interval和number_of_replicas设置为所需的值（默认设置为30s和1）。

 

• 一旦重建索引完成并且新索引的状态是绿色，旧可以删掉旧索引了。