We're looking to scale out our existing database architecture and need some advice on which way to go.

We currently have 2 web servers behind a load balancer that both read & write to a single master database which replicates to a slave.

Ideally, I'd like each of the webservers to point to their own master DB and have the data between the 2 synchronised but from what I've read, using any kind of master-master or ring-replication is discouraged.

I'm looking for a general "what do other people do" kind of answer - database vendor isn't a concern at the moment but we'd like to stay with MySQL or convert to MSSQL.

Any ideas would be gratefully received.

Many thanks,



The next step up before sharding or any other complex db structure changes is to have 1 master server for writes but use multiple replicated servers from this for reads. This assumes that your website/app follows the typical patten of many more reads than writes.

Additionally you could consider setting up a cluster, however this level is often skipped because it is complicated and expensive and scales less well than the newer scalability techniques.

  • One of our main goals is to have redundancy. We'd like to be able to take one master DB server offline and update it whilst the other master server continues to serve and then perform the update on the other master. With the suggested 1 master -> many slaves route, is there a way of having multiple masters with redundancy as well as having replicating slaves? – andrew Apr 8 '10 at 15:09

You could consider sharding your data-sets on multiple servers or use master-slave replication and run all your reads against the slave(s).

You should consider your current workloads, data and whether you can simply get the performance gains you want from upgrading your hardware.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy