Skip to content

Commit 2bc661f

Browse files
authored
Add minimal docs around upgrading clusters with ccr enabled (#38037)
1 parent 8e5ba9a commit 2bc661f

File tree

2 files changed

+50
-0
lines changed

2 files changed

+50
-0
lines changed

docs/reference/ccr/index.asciidoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,7 @@ This guide provides an overview of {ccr}:
2020
* <<ccr-requirements>>
2121
* <<ccr-auto-follow>>
2222
* <<ccr-getting-started>>
23+
* <<ccr-upgrading>>
2324

2425
--
2526

@@ -28,3 +29,4 @@ include::requirements.asciidoc[]
2829
include::auto-follow.asciidoc[]
2930
include::getting-started.asciidoc[]
3031
include::remote-recovery.asciidoc[]
32+
include::upgrading.asciidoc[]

docs/reference/ccr/upgrading.asciidoc

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
[role="xpack"]
2+
[testenv="platinum"]
3+
[[ccr-upgrading]]
4+
== Upgrading clusters
5+
6+
Clusters that are actively using {ccr} require a careful approach to upgrades.
7+
Otherwise index following may fail during a rolling upgrade, because of the
8+
following reasons:
9+
10+
* If a new index setting or mapping type is replicated from an upgraded cluster
11+
to a non-upgraded cluster then the non-upgraded cluster will reject that and
12+
will fail index following.
13+
* Lucene is not forwards compatible and when index following is falling back to
14+
file based recovery then a node in a non-upgraded cluster will reject index
15+
files from a newer Lucene version compared to what it is using.
16+
17+
Rolling upgrading clusters with {ccr} is different in case of uni-directional
18+
index following and bi-directional index following.
19+
20+
[float]
21+
=== Uni-directional index following
22+
23+
In a uni-directional setup between two clusters, one cluster contains only
24+
leader indices, and the other cluster contains only follower indices following
25+
indices in the first cluster.
26+
27+
In this setup, the cluster with follower indices should be upgraded
28+
first and the cluster with leader indices should be upgraded last.
29+
If clusters are upgraded in this order then index following can continue
30+
during the upgrade without downtime.
31+
32+
Note that a chain index following setup can also be upgraded in this way.
33+
For example if there is a cluster A that contains all leader indices,
34+
cluster B that follows indices in cluster A and cluster C that follows
35+
indices in cluster B. In this case the cluster C should be upgraded first,
36+
then cluster B and finally cluster A.
37+
38+
[float]
39+
=== Bi-directional index following
40+
41+
In a bi-directional setup between two clusters, each cluster contains both
42+
leader and follower indices.
43+
44+
When upgrading clusters in this setup, all index following needs to be paused
45+
using the {ref}/ccr-post-pause-follow.html[pause follower API] prior to
46+
upgrading both clusters. After both clusters have been upgraded then index
47+
following can be resumed using the
48+
{ref}/ccr-post-resume-follow.html[resume follower API]].

0 commit comments

Comments
 (0)