Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It only takes a minute to sign up.

There is no hard limit to the number of slaves you can attach to a master, but there is a practical limit and it's based on your workload and hardware. Let's assume that you have a "bunch" of identical machines that you want to stick together in a star topology (1 master, lotsa slaves). In this hypothetical cluster, let's assume that your master became overworked because it reached its maximum capacity of 2000 operations per second where 1000 of them are writes and 1000 are reads (for simplicity, we'll assume that 1 read and 1 write have an equivalent "cost").

So, we add a slave and move all the reads off to the slave. In practice, it is impossible to move all reads to a slave, but this is for the sake of an exercise. Remember, you can't scale writes with replication because the writes have to still happen at each node.

Uh, oh. No matter what we do, we can't improve this situation without either sharding to reduce the writes or by scaling ALL of the servers up so they have a greater capacity for operations per second.

Another consideration is that your master is taking in multiple reads concurrently, but they are serialized into the binary log and then played back in a single thread on the slave. So, while you may be able to keep up with 1000 wps on the master, the slave might only be able to handle 250wps without getting seriously lagged behind. This means that in high-write environments, the slaves may actually need to be more powerful (in terms of CPU and I/O capacity) than the master in order to keep up.

I deal with systems with more than a dozen Slaves hanging off a Master. No problem.

The overhead on the Master is very low -- shove stuff out a socket (per Slave).

It is possible to "fan out", but the "relays" become "single points of failure". That is, the Master could send to a few Relays (both Slave and master), each of which sends to a few Slaves.

Move most reads to the Slaves. This is "read scaling". This will help offload the Master.

Write scaling requires Sharding. (Aaron alludes to this.)

"Dual Master" is two machines that are both Master and Slave to each other. It is handy for failover, but it is not useful for write scaling. Do not write to both machines in a dual-master setup; you are asking for trouble. Instead, have the reads go to the 'backup master'.

Comment on Aaron's numbers -- The master rarely has "0 rps". There are usually a few reads that are necessary to prep for the writes. These are called "critical reads" they cannot be moved to the Slave(s).