CODEWITHSUNDEEP
mongodb
KikoV
KikoV

Reputation: 1009

Master-Master merge replication with MongoDB using mongooplog

I was wondering if it's possible building a master to master merge replication with MongoDB using the mongooplog command.

For example:

# mongooplog --from master2 --host master1
# mongooplog --from master1 --host master2

The problem with this solution is that mongooplog ends when it reaches the last oplog, and it doesn't save the last backed oplog, and it should repeat last n operations.

Is this solution a good approach to solve net splits? How does mongooplog deal with distributed timestamps?

I think it would be a good approach if a primary could accept inserting oplogs from another replica set.

Upvotes: 1

Views: 663

Answers (1)

Stennie
Stennie

Reputation: 65383

Is this solution a good approach to solve net splits? How does mongooplog deal with distributed timestamps?

No, what you're proposing with mongooplog is not possible and will lead to data loss. The MongoDB replication & tool internals assume a common oplog history and idempotent order of operations, and your suggested approach will violate those assumptions.

Multi-master support requires some sort of conflict/merge resolution. MongoDB replication (as at 2.6) is designed to only support a single master (aka "primary").

Replica sets are MongoDB's supported method for automatic failover, so in the event of a net split or server failure you need to plan an appropriate deployment to ensure a primary can be elected.

I think it would be a good approach if a primary could accept inserting oplogs from another replica set.

There is an open request you can upvote/watch in the MongoDB issue tracker: SERVER-2956: Master-Master replication. This is a feature being considered on the longer term roadmap, but is not currently scheduled for a release.

Possible approaches

While not full substitutes for multi-master, there are a few approaches you could consider depending on your deployment requirements:

  • Deploy a sharded cluster using tag-aware sharding to isolate data to certain shards. In a deployment with multiple data centres you can effectively end up with local writes (for data stored on local shards) and local reads (if you're okay with reading from a secondary with eventual consistency).

  • Implement your own API which handles conflict resolution and some multi-master features. An example I've seen (but never tried) is MongoMVCC.

Upvotes: 2

Related Questions