Master-master vs master-slave database architecture?

Question

I've heard about two kinds of database architectures.

• master-master
• master-slave

Isn't the master-master more suitable for today's web cause it's like Git, every unit has the whole set of data and if one goes down, it doesn't quite matter.

Master-slave reminds me of SVN (which I don't like) where you have one central unit that handles things.

Questions:

1. What are the pros and cons of each?
2. If you want to have a local database on your mobile phone like iPhone, which one is more appropriate?
3. Is the choice of one of these a critical factor to consider thoroughly?

Answer 1

Master-Master: This is similar to Master-Slave architecture, the only difference is that both the nodes are masters and replica at the same time i.e. there will be circular replication between the nodes. It is most recommended to configure both the servers to log the transactions from the replication thread (log-slave-updates) but it ignores its own already replicated transactions (set replicate-same-server-id to 0) to prevent infinite loops in the replication.

Master-Slave: In this, as each data has only one master, so consistency is not difficult.   

Advantages of Master-Master Database:

• Masters can be distributed across the network that means in several physical sites master can be located.
• If the one master fails, other masters will start updating the database.

Disadvantages of Master-Master Database:

• This introduces some communication latency, and eager replication systems are complex in this architecture.
• Multi-Master replication systems will be mostly loosely consistent, i.e. asynchronous, lazy and violating ACID properties.
• As the number of nodes involved rises and the required latency decreases, so Issues such as conflict resolution can become intractable.