> I don't understand how MongoDB supports "replica sets", in which it automatically negotiates which server is master, and "fail-over", if it doesn't support "master-master replication".
Those are different things:
In master-master replication, either side can take writes. This is the CouchDB model. The problem is that you get more "eventual" in your eventual consistency. (i.e. you might not read your writes: You can write to one system and read from the other.)
In a replica set, MongoDB allows you to set up 2 "masters", but they flip a coin and one becomes the slave. If the master dies, the slave takes over. Since there's only one master at a time, the system is consistent (all R/W to the master.)
The setup works out to be a lot like MySQL (master/slave with async replication), but with less work. MySQL forces you to micro-manage each box to tell it when it's a master or slave. In fact, Mongo in general feels like a regular database, but without the schema.
I also like the MongoDB philosophy of not worrying about disk. Who wants to wait for their server to reboot and do fsck and then hope that the rarely-used database repair code actually works?