mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-10 23:15:04 +00:00
a0af82c213
* First crack at rewriting the CCR introduction. * Emphasizing Kibana in configuring CCR (part one). * Many more edits, plus new files. * Fixing test case. * Removing overview page and consolidating that information in the main page. * Adding redirects for moved and deleted pages. * Removing, consolidating, and adding redirects. * Fixing duplicate ID in redirects and removing outdated reference. * Adding test case and steps for recreating a follower index. * Adding steps for managing CCR tasks in Kibana. * Adding tasks for managing auto-follow patterns. * Fixing glossary link. * Fixing glossary link, again. * Updating the upgrade information and other stuff. * Apply suggestions from code review * Incorporating review feedback. * Adding more edits. * Fixing link reference. * Adding use cases for #59812. * Incorporating feedback from reviewers. * Apply suggestions from code review * Incorporating more review comments. * Condensing some of the steps for accessing Kibana. * Incorporating small changes from reviewers.
68 lines
2.3 KiB
Plaintext
68 lines
2.3 KiB
Plaintext
[role="xpack"]
|
|
[testenv="platinum"]
|
|
[[ccr-upgrading]]
|
|
=== Upgrading clusters using {ccr}
|
|
++++
|
|
<titleabbrev>Upgrading clusters</titleabbrev>
|
|
++++
|
|
|
|
Clusters that are actively using {ccr} require a careful approach to upgrades.
|
|
The following conditions could cause index following to fail during rolling
|
|
upgrades:
|
|
|
|
* Clusters that have not yet been upgraded will reject new index settings or
|
|
mapping types that are replicated from an upgraded cluster.
|
|
* Nodes in a cluster that has not been upgraded will reject index files from a
|
|
node in an upgraded cluster when index following tries to fall back to
|
|
file-based recovery. This limitation is due to Lucene not being forward
|
|
compatible.
|
|
|
|
The approach to running a rolling upgrade on clusters where {ccr} is
|
|
enabled differs based on uni-directional and bi-directional index following.
|
|
|
|
[[ccr-uni-directional-upgrade]]
|
|
==== Uni-directional index following
|
|
In a uni-directional configuration, one cluster contains only
|
|
leader indices, and the other cluster contains only follower indices that
|
|
replicate the leader indices.
|
|
|
|
In this strategy, the cluster with follower indices should be upgraded
|
|
first and the cluster with leader indices should be upgraded last.
|
|
Upgrading the clusters in this order ensures that index following can continue
|
|
during the upgrade without downtime.
|
|
|
|
You can also use this strategy to upgrade a
|
|
<<ccr-chained-replication,replication chain>>. Start by upgrading clusters at
|
|
the end of the chain and working your way back to the cluster that contains the
|
|
leader indices.
|
|
|
|
For example, consider a configuration where Cluster A contains all leader
|
|
indices. Cluster B follows indices in Cluster A, and Cluster C follows indices
|
|
in Cluster B.
|
|
|
|
--
|
|
Cluster A
|
|
^--Cluster B
|
|
^--Cluster C
|
|
--
|
|
|
|
In this configuration, upgrade the clusters in the following order:
|
|
|
|
. Cluster C
|
|
. Cluster B
|
|
. Cluster A
|
|
|
|
[[ccr-bi-directional-upgrade]]
|
|
==== Bi-directional index following
|
|
|
|
In a bi-directional configuration, each cluster contains both leader and
|
|
follower indices.
|
|
|
|
When upgrading clusters in this configuration,
|
|
<<ccr-pause-replication,pause all index following>> and
|
|
<<ccr-auto-follow-pause,pause auto-follow patterns>> prior to
|
|
upgrading both clusters.
|
|
|
|
After upgrading both clusters, resume index following and resume replication
|
|
of auto-follow patterns.
|