4 ms·
This post doesn't really add anything to the original post from the MongoDB developers other than "replicate for durability". However, the point about "you can
by dmytton 17y ago
This post doesn't really add anything to the original post from the MongoDB developers other than "replicate for durability".
However, the point about "you can only have a replica pair" forgets to mention some key aspects:
- MongoDB supports both master/slave and master/master replication in addition to replica pair. The difference is that the replica pair setup will do automatic failover in the sense that if there is a communication failure where A was the master and B was the slave, and now only B can be reached, B will assume the master status automatically. In contrast, the master/slave setup requires manual failover.
- In the event of a network partition (given as an example in the post that MongoDB does not handle), you are supposed to use an arbitrator server which will have the final say over which instance will assume the master status.
The documentation is clear on this - http://www.mongodb.org/display/DOCS/Replication http://www.mongodb.org/display/DOCS/Replication
- alexpopescu 17y agoI don't think that any of the master/slave and the limited master/master replication are bringing any benefits to durability discussion. These both setups will behave exactly the same as the replica pair. The arbitrator server is an interesting option, but it has to deal with network partition and not durability. Such an arbitrator is not really useful for the replica pairs as these are self-managing the master-slave status.
- andrewtj 17y agoSuch an arbitrator is not really useful for the replica pairs as these are self-managing the master-slave status. From the Mongo documentation: The arbiter is used in some situations to determine which side of a pair is master. In the event of a network partition (left and right are both up, but can't communicate) whoever can talk to the arbiter becomes master. Seems to me that would be useful in ensuring a durable system.
- alexpopescu 17y agoIt is my understanding that the arbiter is useful for the replica pair coordination, but that is not directly related to durability (i.e. the guarantee that once the user has been notified of success, the transaction will persist, and not be undone.)
- andrewtj 17y agoI think the arbiter is quite relevant since a split-brain makes durability impossible.
- alexpopescu 17y agoWould you mind expanding on this? I thought the role of the arbiter is to decide who's the master at one point in time. And while this is helpful for the whole coordination process, (by the way I think a similar effect could be achieved with smart clients) this impacts availability on not durability per se.
- andrewtj 17y agoDescribing the arbiter's role as being to "decide who's the master" is an over-simplification. It's there to achieve quorum without which conflicting updates can occur.