0

I want to replicate a MongoDB database to another node, located in another datacenter. This is to help guard against data loss in the case of a hardware failure.

We don't want/need high availability or elections; just a 'close to live' read-only copy of the database, located in another DC.

Everything I read says that you need an odd number of nodes, due to elections, but this isn't something we need/want and I can't find anything related to just having one primary, and one secondary (I might be being blind).

Is this something we can achieve with MongoDB, and if so are there any 'gotchas' or serious downsides we should consider?

Improve this question

2 Answers 2

Reset to default
2

You could created a Replica Set with a Hidden Member. The hidden member will take a read/only copy of your data. However, if the hidden member goes down then the primary steps down to secondary, i.e. your MongoDB becomes read/only.

You can define an Arbiter. It is not necessary to create the Arbiter service on a dedicated host, define it on your primary node. It is just a small mongod service which consumes almost no CPU/memory resources or disc space.

If you have a Primary + Arbiter on one host and the Hidden Secondary on another host then the second may stop and your application continues running normal. Of course, is your primary goes down then the application is not available anymore.

Improve this answer
5
  • Do you know the purpose why if a hidden member goes down then the primary steps down to secondary? Just curious.
    – Logham
    Commented Oct 24, 2020 at 22:12
  • 1
    Because the majority of all hosts has to be active. I am not 100% sure, maybe I will test it the next days
    – Wernfried Domscheit
    Commented Oct 25, 2020 at 7:21
  • Additional: is there a way to only replicate a single database, or ignore others? The reason is that we have app critical data in one database, and much larger non-critical data in another. We would like to replicate only the critical data, and possibly time delay it on a couple of hidden members. Including the larger databases would use too much disk space.
    – Logham
    Commented Oct 26, 2020 at 17:50
  • 1
    I don't think so, it would clearly contradict the idea of replication. But you could create several mongod instances - just use different ports and of course different dbPath to store the data. For testing I created 10 different mongod instances on a single laptop
    – Wernfried Domscheit
    Commented Oct 26, 2020 at 18:12
  • 1
    Or you could deploy a sharded cluster where one shard is replicated and the other shared is a single node Replicat Set. But this requires also a Config server and the mongos Router. So, maybe an overkill.
    – Wernfried Domscheit
    Commented Oct 26, 2020 at 18:19
1

There is always possibility to use "OpLog tailing" where mongodb node is not part of replica set. It just replication changes of other MongoDB node/replica.

Improve this answer
1
  • 1
    I think there is a disadvantage to use OpLog tailing. The OpLog is periodically truncated. If your backup host is not available for certain time then the copy may not be complete, the backup host needs to be always connected and online. If both nodes are part of a replica set then the OpLog is kept as long as the secondary (i.e. backup host) finished synchronization. Of, course a secondary node also may become STALE - but unlike use OpLog tailing the STALE state is easy to detect. When you use OpLog tailing then you have no (default) indication whether all changes has been caught or not.
    – Wernfried Domscheit
    Commented Oct 25, 2020 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.