[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: |
|
||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
There were once a 'master-master replication' described here : http://www.mongodb.org/display/DOCS/Master+Master+Replication
|
| 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 |
| 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, |
| 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. |
| 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. |
| 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. |
| 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. |
| 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: |