Elasticsearch7.1中文文档-第三章-升级Elasticsearch

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中的每一个产品。 有关更多信息，请参阅“Elastic Stack安装和升级指南”。

从6.7或者更早的版本直接升级到7.1.1，你必须关闭集群，安装7.1.1，而且重启。有关更多信息，请参阅彻底群集从新启动升级。

预升级

升级Elasticsearch以前：

1. 检查弃用日志，查看是否使用了任何弃用特性，并相应地更新代码。默认状况下，当日志级别设置为WARN时，会记录弃用警告。
2. 查看重大更改，对7.1.1的代码和配置进行任何须要的更改。
3. 若是您使用自定义插件，请确保兼容版本可用。
4. 在升级生产群集以前，最好在开发环境中测试升级。
5. 备份您的数据！ 您必须拥有数据快照才能回滚到早期版本。

滚动升级

滚动升级容许Elasticsearch集群一次升级一个节点，所以升级不会中断服务。 不支持在升级期间在同一群集中运行多个版本的Elasticsearch，由于没法将分片已升级的节点复制到运行旧版本的节点。

滚动升级支持：

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

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

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

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" } } '
   复制代码

2. 中止不必的索引而且执行同步刷新。 （可选的）

   在升级过程当中能够继续索引，若是中止不必的索引而且执行同步刷新，那么分片会恢复的快的多。

   curl -X POST "localhost:9200/_flush/synced"
   复制代码

   当你执行同步刷新，检查响应确保结果是成功的。因为挂起索引操做而失败的同步刷新操做被列在响应主体中，尽管请求自己仍然返回200 OK状态。若是出现故障，从新发出请求。

3. 暂时中止与活动机器学习做业和datafeeds相关的任务。(可选)

   若是你在6.x以前建立了机器学习索引，你必须从新索引。

   若是你在6.x中版本中建立了机器学习索引，你能够：

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

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

     curl -X POST "localhost:9200/_ml/set_upgrade_mode?enabled=true"
     复制代码

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

   • 中止全部的做业和datafeeds。此选项在关闭时保存模型状态。 在升级后从新打开做业时，它们使用彻底相同的模型。 可是，保存最新模型状态比使用升级模式须要更长时间，尤为是当您有大量工做或具备大型模型状态的做业时。

4. 关闭一个节点

   • 若是你使用systemd运行Elasticsearch能够这样来关闭：

     sudo systemctl stop elasticsearch.service
     复制代码

   • 若是你使用SysV init运行Elasticsearch能够这样来关闭：

     sudo -i service elasticsearch stop
     复制代码

   • 若是你使用守护进程运行Elasticsearch能够这样来关闭：

     kill $(cat pid)
     复制代码

5. 升级已关闭的节点

   使用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软件包进行安装。

6. 升级插件

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

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

8. 开始升级你的节点

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

   curl -X GET "localhost:9200/_cat/nodes"
   复制代码

9. 启用分片分配

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

   curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
   {
     "persistent": {
       "cluster.routing.allocation.enable": null
     }
   }
   '
   复制代码

10. 等待节点恢复

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

    curl -X GET "localhost:9200/_cat/health?v"
    
    复制代码

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

    在滚动升级期间，新版本的主分片不能分配给旧版本节点。新版本的数据格式和旧版本的数据格式可能不兼容。

    若是没法将复制碎片分配给另外一个节点(集群中只有一个升级的节点)，则复制碎片将保持未分配，状态保持黄色。

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

    一旦升级了另外一个节点，就能够分配副本而且状态将变为绿色。

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

    curl -X GET "localhost:9200/_cat/recovery"
    
    复制代码

    若是您中止索引，能够在恢复完成后当即恢复索引。

11. 重复

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

12. 重启机器学习工做

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

    curl -X POST "localhost:9200/_ml/set_upgrade_mode?enabled=false"
    
    复制代码

    若是您在升级以前关闭了全部机器学习做业，那么打开这些做业并从Kibana或使用打开的做业启动datafeeds并启动datafeeds api。

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

    若是在升级过程当中网络出现故障，将全部剩余的旧节点与群集隔离，则必须使旧节点脱机并升级它们以使其可以加入群集。

    在升级期间，若是一半或者一半以上的主资格节点不可用，则群集将变为不可用，这意味着升级再也不是滚动升级。若是发生这种状况，您应升级并从新启动全部已中止符合主节点资格的节点，再次造成群集，就像执行彻底群集从新启动升级同样。可能还须要升级全部剩余的旧节点，在从新造成后加入群集。

    一样，若是运行仅包含一个主节点的测试/开发环境，则应最后升级主节点。从新启动单个主节点会强制重组群集。新群集最初只有升级后的主节点，重组后，旧节点加入集群时会被拒绝。已升级的节点将成功从新加入集群。

完整集群升级

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

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

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

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" } } '
   
   复制代码

2. 中止不必的索引而且执行同步刷新。

   在升级过程当中能够继续索引，若是中止不必的索引而且执行同步刷新，那么分片会恢复的快的多。

   curl -X POST "localhost:9200/_flush/synced"
   
   复制代码

   当你执行同步刷新，检查响应确保结果是成功的。因为挂起索引操做而失败的同步刷新操做被列在响应主体中，尽管请求自己仍然返回200 OK状态。若是出现故障，从新发出请求。

3. 暂时中止与活动机器学习做业和datafeeds相关的任务。

   若是你在6.x以前建立了机器学习索引，你必须从新索引。

   若是你在6.x中版本中建立了机器学习索引，你能够：

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

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

     curl -X POST "localhost:9200/_ml/set_upgrade_mode?enabled=true"
     
     复制代码

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

   • 中止全部的做业和datafeeds。此选项在关闭时保存模型状态。 在升级后从新打开做业时，它们使用彻底相同的模型。 可是，保存最新模型状态比使用升级模式须要更长时间，尤为是当您有大量工做或具备大型模型状态的做业时。

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插件（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软件包进行安装。

6. 升级插件

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

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

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"
   
   复制代码

9. 等待全部节点加入集群并报告状态为黄色

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

   一旦一个节点恢复了它的本地分片，集群状态就切换到黄色，这代表全部主分片都已恢复，但并无分配全部复制分片。这是预期的，由于您尚未从新启用分配。全部节点状态都变为黄色时，再开始副本的分配，主节点的副本容许被分配到已经具备副本的节点中。

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"
    
    复制代码

11. 重启机器学习工做

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

    curl -X POST "localhost:9200/_ml/set_upgrade_mode?enabled=false"
    
    复制代码

    若是您在升级以前关闭了全部机器学习做业，那么打开这些做业并从Kibana或使用打开的做业启动datafeeds并启动datafeeds api。

升级前从新索引

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

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

有两种方法能够重建旧索引：

• 升级前在老版本上重建索引。
• 建立一个新的7.1.1集群并从远程从新索引。这可以从新索引驻留在运行任何版本的Elasticsearch的集群上的索引。（兼容性强）

重建索引

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

手动重建索引：

1. 建立具备7.x兼容映射的索引。

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

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

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

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

6. 在单个更新别名请求中：

   • 删除旧索引。
   • 将具备旧索引名的别名添加到新索引中。
   • 把旧索引上已存在的别名添加到新索引。

   若是使用机器学习功能而且机器学习索引是在6.x以前建立的，则必须暂时中止与机器学习做业和datafeed相关的任务，防止在从新索引期间打开新做业。 使用set upgrade mode API或中止全部datafeed并关闭全部计算机学习做业。

   若是您使用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>
   
   复制代码

   有关更多信息，请参阅配置文件域。

从远程集群重建索引

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

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

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

迁移索引：

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）。

   • 一旦重建索引完成而且新索引的状态是绿色，旧能够删掉旧索引了。