[SERVER-2956] Master-Master replication Created: 17/Apr/11  Updated: 07/Dec/22  Resolved: 07/Dec/22

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 1.8.0
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: G. Zsombor Assignee: Backlog - Replication Team
Resolution: Won't Do Votes: 51
Labels: master-master, multimaster
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-29231 Why was MongoDB not designed to have ... Closed
Related
is related to SERVER-8990 Support Replication Between Sharded C... Closed
Assigned Teams:
Replication
Participants:

 Description   

There were once a 'master-master replication' described here : http://www.mongodb.org/display/DOCS/Master+Master+Replication
which we used successfully with 1.4.2. However this configuration is not supported anymore, and it's not clear that is it working with newer versions, or can kill our kittens, if we try to use.
Replica sets are not enough for this kind of work, when read, and write response times are extremely crucial to be fast, and we can accept that writes are propagated lazily in the background to the other server(s). So it would be nice, if clients could connect to 'slave' servers in the replica sets, and issue write request. For a write request the following needs to be performed :

  • apply the write request locally
  • respond to the client with success message - so the client see fast response times
  • the write request put into a 'localInitiatedOpLog' queue, which periodically flushed/sent to the actual master server.
  • the master server apply that changes and propagates to all the servers in the replica set. This algorithm will produce some strange effects, if the same object is modified concurrently by different slaves, or by the same slave in rapid succession, but at the end, every node will see the same objects, as the master node decides.


 Comments   
Comment by Asya Kamsky [ 02/Dec/14 ]

smitra you linked to description of "on demand" two-way replication. That does not really match the definition of standard master-master that this ticket describes.

Comment by Suvendu Mitra [ 02/Dec/14 ]

This feature would solve many design issue , please read my post
https://groups.google.com/forum/#!starred/mongodb-user/tG1ekPAaSW0

Comment by Michael Brenden [ 19/Nov/14 ]

Still waiting on this VITAL feature. Please up-vote and join the silent energetic influence!

Comment by Nick Walke [ 09/Jul/13 ]

The auto elections are wonderful, but multi-master would be better.

Comment by Mani [ 14/May/13 ]

Hello Everyone,

Can you recommend any workarounds/external sync tool to achieve this?

Thanks,
Mani

Comment by Ricardo Mayerhofer [ 19/Apr/13 ]

I think the lack of master-master replication is a major drawback of Mongo comparing to other dynamo-like NoSQL solutions. We're looking into Mongo as our single database technology, but we're having a hard time to solve some problems without this feature.

Comment by Michael Brenden [ 06/Mar/13 ]

Master-master is so important. It's causing us to take up Redis. What a split!

Comment by Michael Brenden [ 28/Feb/13 ]

It seems to me that every single telecommuter need this master-master feature.

Imagine

– being on cable or DSL at home

– having a mongo slave on the at-home LAN

– developing write-heavy database

It's painful to wait for every write to hit the distant master. Very painful. Almost more pain than mongo otherwhere alleviates.

Comment by Eliot Horowitz (Inactive) [ 28/Oct/11 ]

If you start both nodes with --master and --slave.
If its insert only - can work ok.

Comment by Adriano Aurelio Meirelles [ 26/Oct/11 ]

Eliot, how I can exactly hack it to force both be master? Which type of inconsistent bad data we are talking about? I mean which kind of updates/inserts operations can lead inconsistent? If of course the application guarantee no collision of keys.

We work with two DCs with 150ms of latency (each other). This is very important for us, also is impossible every write wait that long to reach the master on another continent.

Our application guarantee no key collision on MySQL which works fine for years. Both DCs are totally independent (very failover friend) with eventually consistent read AND write, both amazing fast because the application only use DB servers localized few inches away (in same rack).

Comment by Eliot Horowitz (Inactive) [ 06/Jul/11 ]

It was never supported - you were able to hack it with --master and --slave.
It was no per collection, and easily can lead to inconsistent bad data.

Comment by sam [ 05/Jul/11 ]

Really, the document http://www.mongodb.org/display/DOCS/Master+Master+Replication mentioned is no longer available. Can we get this again?

If this can be done can it be on a collection basis? I mean, can I have a 3-5 server replica set with only one collection that it applies to? This would be ideal.

Thanks

Comment by Eliot Horowitz (Inactive) [ 05/Jul/11 ]

It was never a supported feature, but you can set the system up to do it kind of the same way you can with mysql.
There was never support for conflict resolution, etc... so it's not really a viable thing to use.

Comment by sam [ 05/Jul/11 ]

If this was available at one point why was it removed? Also, since it was done already why would re-enabling the feature be time consuming? Could this be a configuration setting so you could have the option to use sharding or master-master but not both at first with the understanding the features are mutually exclusive?

I as well would like to see this feature in Mongo since it better suits the application(s) I'm working on than sharding.

Thanks

Comment by Kazuki Ohta [ 05/Jul/11 ]

That sounds reasonable, thanks

Comment by Eliot Horowitz (Inactive) [ 05/Jul/11 ]

Its not difficulty per se, but the semantics are very different than current mongo semantics, so there is no "simple" solution.

Comment by Kazuki Ohta [ 05/Jul/11 ]

Sorry, my concern is: Is there any technical difficulty for achieving this? or just scheduling/roadmap issue?

Comment by Eliot Horowitz (Inactive) [ 05/Jul/11 ]

It is something we are planning on doing, but is not schedules for any version at this point.
Though not sure I understand the question.

Comment by Kazuki Ohta [ 05/Jul/11 ]

What makes this "not-planned" status? Just for curious.

Comment by Eliot Horowitz (Inactive) [ 05/Jul/11 ]

It is not on any planned release, though it is something we are interested in looking at in the future.

Comment by Kazuki Ohta [ 05/Jul/11 ]

Planned? Planned in 3 years? not planned?

Comment by sam [ 01/Jul/11 ]

This is what I would like as well and is one of the reasons I'm thinking perhaps Couch is a better approach when this requirement is needed.

Comment by G. Zsombor [ 17/Apr/11 ]

This is the thread, which I've explained our setup & requirements in detail:
http://groups.google.com/group/mongodb-user/browse_thread/thread/625b5e3c30bf1d45/8f635c70b5a8c895

Generated at Thu Feb 08 03:01:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.