This chapter shows you how to build a MySQL architecture that can grow very large while remaining fast and reliable.
Most scaling problems don’t give advance warning; they just appear suddenly one day. If you don’t have a plan to scale your application, you’ll probably have to work hard just to keep it responsive. Companies that can’t scale their applications often fail completely. It’s ironic, but true: too much success can kill your business.
You must also be able to ensure that your application stays up in all circumstances. Many things could interfere, but the most common problems will probably be ordinary hardware and software failures. Your application should treat these as routine and preferably handle them automatically.
The demands for scaling and high availability often go together. High availability isn’t as important when the application is small, for several reasons: it usually runs on a single server, so a server failure is less likely; because it is small, downtime is less likely to cost a lot of money; and the smaller user base is more likely to tolerate downtime. But when you grow to 10 times the number of servers, your probability of a server failing is 10 times higher, and you probably have many more users with higher expectations.
You can make MySQL scale well if you choose the right architecture and implement it well. The same is true for guaranteeing high availability. In this chapter, we break these concepts apart as much ...