<commit_before>[[rolling-upgrades]]
== Rolling upgrades

A rolling upgrade allows an Elasticsearch cluster to be upgraded one node at
a time so upgrading does not interrupt service. Running multiple versions of
Elasticsearch in the same cluster beyond the duration of an upgrade is
not supported, as shards cannot be replicated from upgraded nodes to nodes
running the older version.

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 <<restart-upgrade,
full cluster restart>>. You must <<reindex-upgrade,reindex to upgrade>> from
versions prior to 5.x.

WARNING: If the {es} {security-features} are enabled on your 5.x cluster, before
you can do a rolling upgrade you must encrypt the internode-communication with
SSL/TLS, which requires a full cluster restart. For more information about this
requirement and the associated bootstrap check, see <<bootstrap-checks-tls>>.

To perform a rolling upgrade:

. *Disable shard allocation*.
+
--<commit_msg>[DOCS] Rolling upgrade with old internal indices (#37184)<commit_after>[[rolling-upgrades]]
== Rolling upgrades

A rolling upgrade allows an Elasticsearch cluster to be upgraded one node at
a time so upgrading does not interrupt service. Running multiple versions of
Elasticsearch in the same cluster beyond the duration of an upgrade is
not supported, as shards cannot be replicated from upgraded nodes to nodes
running the older version.

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 <<restart-upgrade,
full cluster restart>>. You must <<reindex-upgrade,reindex to upgrade>> from
versions prior to 5.x.

WARNING: If the {es} {security-features} are enabled on your 5.x cluster, before
you can do a rolling upgrade you must encrypt the internode-communication with
SSL/TLS, which requires a full cluster restart. For more information about this
requirement and the associated bootstrap check, see <<bootstrap-checks-tls>>.

WARNING: The format used for the internal indices used by Kibana and {xpack}
has changed in 6.x. When upgrading from 5.6 to 6.x, these internal indices have
to be {stack-ref}/upgrading-elastic-stack.html#upgrade-internal-indices[upgraded]
before the rolling upgrade procedure can start. Otherwise the upgraded node will
refuse to join the cluster.

To perform a rolling upgrade:

. *Disable shard allocation*.
+
--
{'fraction_non_alphanumeric': 0.060117878192534384, 'fraction_numerical': 0.008251473477406679, 'mean_word_length': 4.990588235294117, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4547262', 'n_tokens_mistral': 666, 'n_tokens_neox': 620, 'n_words': 346}