# How to install the repository plug-in in a rolling upgrade to ensure that business reading and writing are not affected **URL:** \ **Category:** Elasticsearch\ **Created:** [April 17, 2026, 2:55am UTC](https://discuss.elastic.co/t/how-to-install-the-repository-plug-in-in-a-rolling-upgrade-to-ensure-that-business-reading-and-writing-are-not-affected/385924 "2026-04-17T02:55:32Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![mloine](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mloine/32/146901_2.png) [@mloine](https://discuss.elastic.co/u/mloine)\ **Post date:** [April 17, 2026, 2:55am UTC](https://discuss.elastic.co/t/how-to-install-the-repository-plug-in-in-a-rolling-upgrade-to-ensure-that-business-reading-and-writing-are-not-affected/385924/1 "2026-04-17T02:55:32Z")
Background: Because the business scenario does not allow downtime maintenance and there will be a large number of read and write operations during the period, only rolling installation of plug-ins can be considered The version is 6.8.1, 3 master nodes, 30 data nodes, index 1 replica configuration Refer to the official documentation [Full Cluster restart and rolling restart procedures | Elastic Docs](https://www.elastic.co/docs/deploy-manage/maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures) I understand that after each node is restarted, it needs to be restored to cluster.routing.allocation.enable=all; to avoid that the replica cannot catch up with the actual primary shard data after the restart, resulting in the situation that there is no latest data shard during the rolling restart; is this understanding correct? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [April 17, 2026, 10:36am UTC](https://discuss.elastic.co/t/how-to-install-the-repository-plug-in-in-a-rolling-upgrade-to-ensure-that-business-reading-and-writing-are-not-affected/385924/2 "2026-04-17T10:36:02Z")
> [@mloine](#): > > The version is 6.8.1, 3 master nodes, 30 data nodes, index 1 replica configuration This version is ancient - you need to upgrade to a supported version as a matter of some urgency. You can do this upgrade in a rolling fashion, first to 7.17.29 and then again to 8.19.14 which is a currently-supported version. All currently-supported versions have built-in repository functionality, no need to install any plugins. ---
**Author:** ![mloine](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mloine/32/146901_2.png) [@mloine](https://discuss.elastic.co/u/mloine)\ **Post date:** [April 18, 2026, 3:32am UTC](https://discuss.elastic.co/t/how-to-install-the-repository-plug-in-in-a-rolling-upgrade-to-ensure-that-business-reading-and-writing-are-not-affected/385924/3 "2026-04-18T03:32:57Z")
Upgrades are no longer planned; Does this case mean that the 6.8.1 version is not recommended to use the snapshot feature? If so, why? ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [April 18, 2026, 3:56am UTC](https://discuss.elastic.co/t/how-to-install-the-repository-plug-in-in-a-rolling-upgrade-to-ensure-that-business-reading-and-writing-are-not-affected/385924/4 "2026-04-18T03:56:05Z")
> [@mloine](#): > > Does this case mean that the 6.8.1 version is not recommended to use the snapshot feature? If so, why? Version 6.8 reached EOL more than 4 years ago, this specific version, 6.8.1, was released almost 7 years ago, it is an ancient unsupported version. I don't think it is recommended to use this version anymore. ---
**Author:** ![spiderrr](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spiderrr/32/147375_2.png) [@spiderrr](https://discuss.elastic.co/u/spiderrr)\ **Post date:** [April 20, 2026, 9:43am UTC](https://discuss.elastic.co/t/how-to-install-the-repository-plug-in-in-a-rolling-upgrade-to-ensure-that-business-reading-and-writing-are-not-affected/385924/5 "2026-04-20T09:43:40Z")
Thanks for sharing the detailed background. I've dealt with similar constraints on legacy clusters (no downtime, large read/write volume). To answer your specific question about `cluster.routing.allocation.enable=all`: **Yes, your understanding is essentially correct.** During a rolling restart, you typically want to: 1. Disable allocation temporarily (`none`) to prevent shard thrashing. 2. Restart the node. 3. Set back to `all` so the cluster rebalances gradually. However, on 6.8.1, you also need to watch for **replica sync delays** after each node returns. The primary shard may have new writes during the node's downtime, and the replica can take time to catch up. Setting `all` too early can cause routing decisions based on stale replica metadata.