From 98a547f3098b7379f7c8dec5b050da656a2a54bc Mon Sep 17 00:00:00 2001 From: Jozef Kralik Date: Fri, 14 Jun 2024 07:10:20 +0000 Subject: [PATCH] disaster-recovery: add replica-set option --- .../disaster-recovery.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/content/en/docs/features/monitoring-and-diagnostics/disaster-recovery.md b/content/en/docs/features/monitoring-and-diagnostics/disaster-recovery.md index 5530c35c..b3dcac16 100644 --- a/content/en/docs/features/monitoring-and-diagnostics/disaster-recovery.md +++ b/content/en/docs/features/monitoring-and-diagnostics/disaster-recovery.md @@ -70,8 +70,20 @@ To back up the database, two approaches can be used: ![active-backup](/docs/features/monitoring-and-diagnostics/static/disaster-recovery-active-backup.drawio.svg) - The database actively synchronizes data between two clusters in realtime. This approach is more complex and resource-intensive but is more reliable for disaster recovery. For MongoDB, use `cluster-to-cluster-sync` feature to synchronize data between two MongoDB clusters. For more details on this approach, refer to the [MongoDB documentation](https://www.mongodb.com/docs/cluster-to-cluster-sync/current/connecting/onprem-to-onprem/). + The database actively synchronizes data between two clusters in real-time. This approach is more complex and resource-intensive but is more reliable for disaster recovery. For MongoDB, use: + * `replica-set-sync`: The primary and secondary cluster MongoDB members are in the same MongoDB replica set. The secondary cluster members are configured as [hidden](https://www.mongodb.com/docs/manual/core/replica-set-hidden-member), [delayed](https://www.mongodb.com/docs/manual/core/replica-set-delayed-member/), and with [zero priority](https://www.mongodb.com/docs/manual/core/replica-set-priority-0-member/). When the primary cluster goes down, the secondary cluster MongoDB members are promoted to secondary state—one of them will become primary. After the primary is back online, the primary cluster members will be demoted to hidden. For switching back, the primary cluster members will be promoted to secondary MongoDB members and secondary cluster members will be demoted. **This approach is supported by plgd hub helm chart**. For setup instructions, please refer to this [tutorial](). + + {{< note >}} + This is compliant with the MongoDB Community Server license. For more information, refer to the [MongoDB Server Side Public License](https://www.mongodb.com/licensing/server-side-public-license). + {{< /note >}} + + * `cluster-to-cluster-sync`: A feature to synchronize data between two MongoDB clusters. For more details on this approach, refer to the [MongoDB documentation](https://www.mongodb.com/docs/cluster-to-cluster-sync/current/connecting/onprem-to-onprem/). + + {{< note >}} + The licensing of the MongoDB cluster-to-cluster sync feature **is not compliant with the MongoDB Community Server**. For more information, refer to the [mongosync package LICENSE file](https://fastdl.mongodb.org/tools/mongosync/mongosync-amazon2-x86_64-1.7.3.tgz). + {{< /note >}} + {{< warning >}} **Using a backup from EventBus (JetStream) is not recommended in a restored cluster**, as it is not the source of truth for the plgd hub. This could result in data inconsistency because creating backups is not synchronized for both EventStore and EventBus (JetStream). The EventBus can contain events that are not stored in the EventStore, and vice versa.