Re: Suggested MySQL architecture for scaling out

[David Ashman]

MySQL Cluster is it's own entity, unrelated to master-slave replication setups so you might get more feedback in the Replication forum.

However to answer your question, the downsides to master-master replication are conflicting writes and how you handle new records. If someone updates row 10 on Server A, your application would have to make sure nobody else updates row 10 on any other server since the database can't enforce that. This is extra important if replication breaks/lags to one server. If writes are going through to that server but it's not replicating out, you have to come up with a plan for how you handle those changes. You also have to make sure that if someone inserts a new record on a server with id=100, none of the other servers will try to use that same id.

> My trouble is that each of my web service does both read and write MySQL cycles. For instnace a web service (lets call WS1), does some mysql select/join queries and also carries out updation of certain fields in a few tables.

The solution to that is to just create two connection objects: one that opens a connection to the write database and the other that connects to the read-only database.