Skip to content

DOC-13931-update the step for disaster recovery #950

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
iamfortune wants to merge 3 commits into
base: release/4.0
Choose a base branch
from
+10 −9
Open

DOC-13931-update the step for disaster recovery #950

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
caa7954
update the step for disaster recovery
iamfortune Jan 29, 2026
93790df
update to compile to style guide
iamfortune Jan 30, 2026
e6341c5
update set up text
iamfortune Feb 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 10 additions & 9 deletions modules/deploy/pages/setting-up-dr-cluster.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,9 +87,6 @@ It includes an optional optimization step, which confirms that there is no downt
.Set Up
To set up and maintain a disaster recovery cluster:

. [*Optional step -- for optimization*] Start Sync Gateway with `offline: true` in the Disaster Recovery cluster to asynchronously create indexes.
Creating all indexes beforehand reduces switching costs. +
If you skip this test, you'll incur latency when Sync Gateway switches to the Disaster Recovery cluster and Sync Gateway rebuilds its indexes.
Comment on lines -90 to -92
Copy link
Member

@bbrks bbrks Feb 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to figure out how to reword this so that Sync Gateway's indexes are initialised on the DR cluster similar to the previous description.

It may be that the SG cluster needs to be configured to point to this DR cluster first, with an offline database to init the indexes, then switch it back to primary before continuing.

At least then, with the indexes in place, they can be updated in the background as XDCR runs and are ready for the switch-over to minimise downtime.

Copy link
Contributor Author

@iamfortune iamfortune Feb 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the text to address the gap between initialization and the critical step to keep DR SGs offline in a new commit.

. Connect Sync Gateway to your Primary cluster.
. Start the *unidirectional* XDCR from the Primary cluster to the Disaster Recovery cluster.

Expand All @@ -101,9 +98,8 @@ image::ROOT:{image-sgw-xdcr-dr-same-regn-setup}[,{std-image-size}]
When you're ready to switch to Disaster Recovery operations:

. Stop the replication (XDCR) from the Primary cluster to Disaster Recovery cluster.
. *After you stop XDCR:* Switch the Load Balancer to point to the Sync Gateway on the Disaster Recovery cluster.
This approach keeps the deployment of Sync Gateway at only 1 end of the XDCR replication.
. Promote the Disaster Recovery cluster to Primary and the *old* Primary to Disaster Recovery.
. Reconfigure the Sync Gateway cluster to connect to the Disaster Recovery cluster instead of the Primary cluster.
. Make the Disaster Recovery cluster the *new* Primary and the *old* Primary the *new* Disaster Recovery.
. Flush all replicated buckets in the Primary cluster as a precaution against any spurious writes that enter the Primary cluster and XDCR fails to replicate when you stop it.
. Reverse the XDCR to replicate from the newly promoted Primary to the old Primary to set up a new Backup.

Expand All @@ -124,9 +120,14 @@ The optional optimization step confirms that there is no downtime during the act
.Set Up
To set up and maintain a disaster recovery cluster - see: <<fig-dr-diff-regn-setup>>:

. [*Optional step -- for optimization*] Start Sync Gateway with `offline: true` in the Disaster Recovery cluster to asynchronously create indexes.
If you skip this test, you'll incur latency when you switch Sync Gateway to the Disaster Recovery cluster and Sync Gateway rebuilds its indexes.
. [*Critical step*] Turn off *all* the Sync Gateways in the Disaster Recovery cluster.
. [*Optional step -- for optimization*] Initialize Sync Gateway indexes on the Disaster Recovery cluster:
.. Configure Sync Gateway to point to the Disaster Recovery cluster.
.. Start the database in offline mode (`offline: true` in the database configuration) to build indexes asynchronously.
.. Once indexes are created, shut down Sync Gateway on the Disaster Recovery cluster.
+
This pre-initialization allows XDCR to maintain the indexes in the background during normal operations, reducing latency during disaster recovery activation.
If you skip this step, you'll incur latency when switching to the Disaster Recovery cluster as Sync Gateway rebuilds its indexes from scratch.
. [*Critical step*] Ensure *all* Sync Gateways in the Disaster Recovery cluster remain offline.
. Start the *unidirectional* XDCR from the Primary cluster to the Disaster Recovery cluster.

[#fig-dr-diff-regn-setup]
Expand Down