[ycombasks]

You're absolutely right. How about your MySQL write server? You typically have one master that you update to and one or more slaves where you read from. If you get a sudden burst of traffic and your master can't handle all the writes, what do you do?

[mobiplayer]

I understand how HTTP works so I know how to scale it, but unfortunately I don't have the knowledge to scale DB infrastructure.

Anything I say would be a shot in the dark, but I'm interested on your point of view about this one. Caching? Write on two servers? In the second case do you setup a cluster or you just load balance it with a third device/service?

[ycombasks]

I'm still learning this myself, but from the research I've done I've figured this out:

1. Most people don't go with two writes to a relational database (like MySQL). Syncing is hard, and when it is done, it loses its relational features. 2. Common set up is one mysql write server, scaling it up to fit your traffic, and automatically syncing it with additional servers where SELECT statements only will be made. A random read server is selected if there are multiple to choose from. 3. This also means that in the application, doing a write and immediate read on what you just wrote won't work, so you have to code your application around that. 4. In you app you separate your connections for the reads and writes.

Now, in terms of making changes to the write server is what I'm trying to figure out. Perhaps there's a way to make upgrades on one of the slaves (the reads), then automatically make that slave the master and the master a slave? Not sure, I'm reading a MySQL book (The MySQL Bible) right now that I hope will point me in the right direction.

[mobiplayer]

Well, that was quite interesting, thank you!

[ycombasks]

No problem!