升级Elasticsearch

升级Elasticsearch

通常可以使用滚动升级过程升级Elasticsearch，这样升级就不会中断服务。支持滚动升级:

• Between minor versions
• From 5.6 to 6.8
• From 6.8 to 7.2.0

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

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

要从6.7或更早版本直接升级到7.2.0，必须关闭群集，安装7.2.0，然后重新启动。 有关更多信息，请参阅完全群集重新启动升级

准备升级

在升级之前Elasticsearch:

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

检查中断的更改，并对7.2.0的代码和配置进行任何必要的更改。

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

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

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

滚动升级

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

支持滚动升级：

在次要版本之间

从5.6到6.8

从6.8到7.2.0

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

要执行从6.8到7.2.0的滚动升级：

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状态。如果出现故障，重新发出请求。

3.暂时停止与活动机器学习作业和数据存储相关的任务。(可选)

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

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

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

暂时停止与计算机学习作业和数据馈送相关的任务，并使用设置的upgrade mode API阻止打开新作业：

POST _ml/set_upgrade_mode?enabled=true

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

停止所有数据存储并关闭所有作业。此选项保存关闭时的模型状态。升级后重新打开作业时，它们使用完全相同的模型。但是，保存最新的模型状态要比使用升级模式花费更长的时间，特别是如果您有许多作业或具有较大模型状态的作业。

4. 关闭单个节点

如果你用systemd运行Elasticsearch:

sudo systemctl stop elasticsearch.service

如果你用SysV init运行Elasticsearch:

sudo -i service elasticsearch stop

如果你是作为一个守护进程运行Elasticsearch:

kill $(cat pid)

5. 升级关闭的节点

使用Debian或RPM包升级:

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

使用zip或压缩压缩包升级:

将zip或tarball解压缩到一个新目录。如果不使用外部配置和数据目录，这一点非常重要。

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

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

重要的

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

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

提示

当您解压缩zip或tarball包时，elasticsearch-n.n.n目录包含Elasticsearch配置，数据，日志和插件目录。

我们建议将这些目录移出Elasticsearch目录，这样在升级Elasticsearch时就没有机会删除它们。要指定新位置，请使用ES_PATH_CONF环境变量和路径。数据和路径。日志设置。有关更多信息，请参见重要的Elasticsearch配置。

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

6. 升级任何插件

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

7. 如果使用Elasticsearch安全特性定义领域，请验证您的领域设置是最新的。域设置的格式在version 7.0中发生了更改，特别是域类型的位置发生了更改。See Realm settings

8.启动升级后的节点

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

GET _cat/nodes

9. 启用分片分配。

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

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

10. 等待节点恢复

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

GET _cat/health?v

等待状态列从黄色切换到绿色。一旦节点为绿色，就分配了所有主分片和副本分片

重要:

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

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

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

一旦升级了另一个节点，就可以分配副本并且状态将变为绿色。

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

GET _cat/recovery

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

11.重复

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

12.启动机器学习任务

如果您临时停止了与机器学习任务相关的任务，请使用set upgrade mode API将它们返回到活动状态:

POST _ml/set_upgrade_mode?enabled=false

如果在升级之前关闭了所有的机器学习作业，打开作业并从Kibana或打开作业并启动datafeeds并启动datafeed api。

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

在升级过程中出现网络故障(将所有剩余的旧节点与集群隔离)的可能性很小的情况下，您必须使旧节点脱机并升级它们，以使它们能够加入集群。

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

全集群重启升级

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

请注意

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

要执行完整的集群重启升级到7.2.0:

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状态。如果出现故障，重新发出请求。

3.暂时停止与活动机器学习作业和数据存储相关的任务。(可选)

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

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

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

暂时停止与计算机学习作业和数据馈送相关的任务，并使用设置的upgrade mode API阻止打开新作业：

POST _ml/set_upgrade_mode?enabled=true

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

停止所有数据存储并关闭所有作业。此选项保存关闭时的模型状态。升级后重新打开作业时，它们使用完全相同的模型。但是，保存最新的模型状态要比使用升级模式花费更长的时间，特别是如果您有许多作业或具有较大模型状态的作业。

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或压缩压缩包升级:

将zip或tarball解压缩到一个新目录。如果不使用外部配置和数据目录，这一点非常重要。

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

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

重要:

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

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

提示:

当您解压缩zip或tarball包时，elasticsearch-n.n.n目录包含Elasticsearch配置，数据，日志和插件目录。

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

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

6.升级任意插件

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

7. 如果使用Elasticsearch安全特性定义领域，请验证您的领域设置是最新的。域设置的格式在version 7.0中发生了更改，特别是域类型的位置发生了更改。See Realm settings

8.启动升级后的每个节点

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

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

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

GET _cat/health
GET _cat/nodes

_cat/health返回的状态列显示集群中每个节点的健康状况:红色、黄色或绿色。

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

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

一旦节点恢复其本地分片，群集状态将切换为黄色，表示已恢复所有主分片，但并未分配所有副本分片。 这是预料之中的，因为您还没有重新启用分配。 延迟副本的分配直到所有节点都为黄色允许主节点将副本分配给已经具有本地分片副本的节点。

10. 启用分配

当所有节点都加入集群并恢复其主碎片时，通过恢复cluster.routing.allocation来重新启用分配。启用其默认值:

11.重复

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

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

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

GET _cat/health
GET _cat/recovery

12.重启机器学习任务

如果您临时停止了与机器学习任务相关的任务，请使用set upgrade mode API将它们返回到活动状态:

POST _ml/set_upgrade_mode?enabled=false

如果在升级之前关闭了所有的机器学习作业，打开作业并从Kibana或打开作业并启动datafeeds并启动datafeed api。

升级前重建索引

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

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

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

在升级之前，在6.x群集上重新编制索引。

从远程创建一个新的7.2.0集群和Reindex。 这使您可以重新索引驻留在运行任何版本的Elasticsearch的集群上的索引。

升级基于时间的指数

如果使用基于时间的指数，则可能不需要将6.x之前的指数前调至7.2.0。随着时间的推移，基于时间的索引中的数据通常变得不那么有用，并且随着它们超过保留期而被删除。

除非您的保留期非常长，否则您可以等到升级到6.x，直到删除所有6.x之前的索引。

Reindex in place

您可以使用Kibana 6.8中的升级助手自动重新索引您需要结转到7.2.0的5.x索引。

要手动重新索引旧索引：

使用7.x兼容映射创建索引。

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

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

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

等待索引状态变为绿色。

在单个更新别名请求中：

删除旧索引。

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

将旧索引上存在的任何别名添加到新索引。

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

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

1.在单个节点上，向文件域添加一个临时超级用户帐户。例如，运行elasticsearch-users useradd命令:

bin/elasticsearch-users useradd <user_name> \

-p <password> -r superuser

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

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

bin/elasticsearch-users userdel <user_name>

更多的信息, 查看 Configuring a file realm

Reindex from a remote cluster

您可以使用reindex from remote将索引从旧集群迁移到新的7.2.0集群。这使您可以在不中断服务的情况下从6.8之前的集群迁移到7.2.0。

注意:

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

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

要迁移索引：

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

reindex.remote.whitelist: oldhost:9200

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

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

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

使用reindex API将文档从远程索引拖放到新的7.2.0索引中:

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在后台运行reindex作业，则reindex请求将返回一个task_id，您可以使用该任务API监视reindex作业的进度：

GET _tasks / TASK_ID

c. 当reindex作业完成时，将refresh_interval和number_of_replicas设置为所需的值(默认设置为30s和1)。

d. 当重新索引完成并且新索引的状态为绿色时，可以删除旧索引。