Skip to content

Commit

Permalink
disaster-recovery: add replica-set option
Browse files Browse the repository at this point in the history
  • Loading branch information
jkralik committed Jun 14, 2024
1 parent e351f3c commit 98a547f
Showing 1 changed file with 13 additions and 1 deletion.
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down

0 comments on commit 98a547f

Please sign in to comment.