滾動升級 · my-elasticsearch-cn

# 滾動升級滾動升級允許用戶每次升級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.