I am trying to achieve a Disaster recovery for Mongo DB

I've discovered MongoShake (https://github.com/alibaba/MongoShake) which is an open source Golang application which does cluster to cluster replication and has been made by Alibaba.

The documentation is focused on its internal work/behaviour, and can be discouraging but you have to look at the example configuration file instead which describe each configuration options (https://github.com/alibaba/MongoShake/blob/develop/conf/collector.conf). In the majority of the cases, as far as I understood it (not tried it yet), you have 2 options to configure:

• mongo_urls which tells where is/are the MongoDB source(s)
• tunnel.address which tells to where the data should be synced

This allows you to replicate, asynchronously, a MongoDB cluster from one datacenter to another one.

There is also a 48 minutes tutorial video on YouTube which explains all the replication you can achieve with MongoShake, and also shows a demo of a MongoDB cluster in Singapour replicating to Jakarta, Indonesia.

This solution is quite young, and there is no English blog article showing it, nor official Docker image on Docker Hub (only 3 images without any documentation ?).

To me it look promising and needs more write/test/love to rise.

As per your requirement it seems like that only you want two Data Center (i.e HA(primary or Data Center 1) & DR (Secondary or Data Center 2)).

As per MongoDB documentation Priority 0 Replica Set Members

One data center hosts the primary and a secondary. A second data center hosts a secondary with priority 0. Only the members in data center 1 can become primary.

A priority 0 member is a member that cannot become primary and cannot trigger elections. Priority 0 members can acknowledge write operations issued with write concern of w : . For "majority" write concern, the priority 0 member must also be a voting member (i.e. members[n].votes is greater than 0) to acknowledge the write. Non-voting replica set members (i.e. members[n].votes is 0) cannot contribute to acknowledging write operations with "majority" write concern.

Other than the aforementioned restrictions, secondaries that have priority 0 function as normal secondaries: they maintains a copy of the data set, accept read operations, and vote in elections.

Configure a secondary to have priority 0 to prevent it from becoming primary, which is particularly useful in multi-data center deployments.

for further your ref here and here