# 滚动升级 滚动升级允许用户每次升级Elasticsearch集群中的一个节点，终端用户感受不到任何停机。升级期间在同一个集群中会允许多个不同版本的Elasticsearch，正常生产期间不允许这样允许，因为新版本的分片副本将不会存放到老版本上。 Rolling upgrades can be performed between minor versions. Elasticsearch 6.x supports rolling upgrades from Elasticsearch 5.6. Upgrading from earlier 5.x versions requires a [full cluster restart](https://www.elastic.co/guide/en/elasticsearch/reference/6.0/restart-upgrade.html "Full cluster restart upgrade"). You must [reindex to upgrade](https://www.elastic.co/guide/en/elasticsearch/reference/6.0/reindex-upgrade.html "Reindex before upgrading") from versions prior to 5.x. 执行滚动升级： 1. **禁用分片分配** 当你关闭一个节点时，分配进程在等待一分钟之后开始将此节点上的分片复制到其它节点中，会造成很多浪费的I/O。这可以在节点关闭前通过禁用分片分配来避免： ``` PUT _cluster/settings { "transient": { "cluster.routing.allocation.enable": "none" } } ``` 2. **停止不必要的索引库和执行一个同步冲刷(可选)** 你可以愉快地继续索引在升级。但是，如果你临时地关闭一些非不要的索引库以及执行一次[同步冲刷](../../Indices_APIs/Flush/Synced_Flush.md)请求可以帮助你快速恢复分片： ``` POST _flush/synced ``` 同步冲刷请求是一个”尽力而为“的操作。它可能会因为一些正在进行的索引操作而失败，但是如果有必要你可以反复的执行它，这是安全的。 3. **停止一个节点** * If you are running Elasticsearch with `systemd`: ``` sudo systemctl stop elasticsearch.service ``` * If you are running Elasticsearch with SysV `init`: ``` sudo -i service elasticsearch stop ``` * If you are running Elasticsearch as a daemon: ``` kill $(cat pid) ``` 4. **升级你停止的节点** 升级采用[Debain](../Installing_Elasticsearch/Install_Elasticsearch_with_Debian_Package.md)与[RPM](../Installing_Elasticsearch/Install_Elasticsearch_with_RPM.md)安装包： - 使用`rpm`与`dpkg`安装包升级时，所有的文件都会被放置在合适的位置，且配置文件不会被覆盖。 如果升级采用`zip`或`tar`包： - 解压`zip`或`tar`包到一个新的目录，确保不会覆盖`config`或`data`目录。 - Set the `ES_PATH_CONF` environment variable to specify the location of your external `config` directory and `jvm.options` file. If you are not using an external `config` directory, copy your old configuration over to the new installation. - Set `path.data` in `config/elasticsearch.yml` to point to your external data directory. If you are not using an external `data` directory, copy your old data directory over to the new installation. - Set `path.logs` in `config/elasticsearch.yml` to point to the location where you want to store your logs. If you do not specify this setting, logs are stored in the directory you extracted the archive to. > 提示 > > When you extract the zip or tarball packages, the elasticsearch-n.n.n directory contains the Elasticsearh config, data, logs and plugins directories. >We recommend moving these directories out of the Elasticsearch directory so that there is no chance of deleting them when you upgrade Elasticsearch. To specify the new locations, use the ES_PATH_CONF environment variable and the path.data and path.logs settings. For more information, see Important Elasticsearch configuration. >The Debian and RPM packages place these directories in the appropriate place for each operating system. In production, we recommend installing using the deb or rpm package. 5. **升级所有的插件** 使用`elasticsearch-plugin`脚本安装你所有需要插件的正确版本。升级Elasticsearch 节点时必须升级插件。 6. **启动升级的节点** 现在开始启动升级的节点，并通过日志文件或如下命令来确认此节点能加入集群： ``` GET _cat/nodes ``` 7. **重新打开分片分配** Once the node has joined the cluster, reenable shard allocation to start using the node: ``` PUT _cluster/settings { "transient": { "cluster.routing.allocation.enable": "all" } } ``` 8. **等待节点的恢复** 在升级下一个节点前你需要等待集群完成分片的分配工作。你可以通过[\_cat/health](../../cat_APIs/cat_health.md)来检查完成得进度： ``` GET _cat/health ``` 一直等待`status`这一列的值从`yellow`变为`green`。状态`green`表示所有的主分片与副本分片都已分配完成。 > 重要 > > 在滚动升级期间，主分片如果被分配到高版本的节点，那么副本将不会被分配到低版本的节点。这是因为新版本可能是不同的数据格式，低版本不能识别它。 > > 如果不能将分片分配到其它高版本的节点（譬如：集群中只有一个高版本的节点），副本分片将被遗留成未分配的分片，且集群状态会变成`yellow`。 > > 遇到这种场景时，在开始后续的工作之前你需要检查下未初始化或未迁移的分片（在`init`与`relo`列中）。 > > 一旦另一个节点升级，副本分片将会被分配且集群的健康状态将会变成`green`。 分片没有被[同步冲刷](../../Indices_APIs/Flush/Synced_Flush.md)则可能还需要一些时间来恢复。单个分片的恢复状态可以通过[\_cat/recovery](../../cat_APIs/cat_recovery.md)请求来监控： ``` GET _cat/recovery ``` 如果你停止新增索引，那在集群尽快完成恢复后重新开始新增索引是安全的做法。 9. **重复以上步骤** 当集群和节点恢复稳定后，所有剩余的节点重复以上步骤。 > 重要提示 > > During a rolling upgrade, the cluster continues to operate normally. However, any new functionality is disabled or operates in a backward compatible mode until all nodes in the cluster are upgraded. New functionality becomes operational once the upgrade is complete and all nodes are running the new version. Once that has happened, there’s no way to return to operating in a backward compatible mode. Nodes running the previous major version will not be allowed to join the fully-updated cluster. > In the unlikely case of a network malfunction during the upgrade process that isolates all remaining old nodes from the cluster, you must take the old nodes offline and upgrade them to enable them to join the cluster.