3 ms·
I 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
by alexpopescu 17y ago
I 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.