What is the best way to set up a master-master rig?

Question

Because everyone says master-master is not recommended.

But if you think about it...1 write server is hardly enough!

So, how would you set it up (high-level, not tutorial-level) so that it works out well?

Answer 1

When I think about it, I realise that one writable server is plenty. HA takes care of availability, and sharding takes care of capacity.

Answer 2

Even if you have some sort of absurd application that needs to do trillions of writes, you'd probably be better off just having a number of unconnected servers available through some sort of round-robin interface, and just combining the data later in a more controlled environment...There is virtually no way to be sure of replication when you're getting hammered like that.

In the end though, most database applications don't perform many writes in comparison to the reads.

Answer 3

I think you'll find that most of your problems can be solved by other means: eg

SELECTS queueing up behind UPDATES that take ages:

• Switch to InnoDB

Too many selects for 1 machine to handle:

• Go for a master -> many slaves setup. It's much easier to maintain, you just need to modify your application to write to one DB and select from another.

Answer 4

Given that some of the largest sites in the world run off of single master instances, your premise is flawed. The way to solve your problem is to insert a caching layer (memcached for non-persistent data and something like CouchDB for persistent data) and avoid the database like the plague. Put into place asynchronous processes to insert data into the database and realize that users rarely need to see data that is up-to-date...a few seconds or minutes behind is usually ok. Sharding and multi-master setups are just panacea to get around the architectural changes that will really speed up your system.