There are no limits in terms of settings, but you need to be cognizant of some aspects.
You could use semisynchrnous replication as it uses a nice algorithm for shipping SQL to Slaves by making sure at least one server has all the latest SQL in the Slaves relay logs. (See my August 5, 2011 post Is MySQL Replication Affected by a High-Latency Interconnect?)
However, semisynchronous replication is only good for one out of N Slaves.
Whether you have semisynchronous replication or not, it would suffice to say that the more Slaves you have, the more CPU processing a Master has to do to keep its Slaves up-to-date.
For a Master with N Slaves, that's...
- N SQL Statements to send to Slave
- N Acknowledgments from Slaves 1-N that SQL was Executed
With semisynchrnous replication, it is not much better because For a Master with N Slaves, that's ...
- N SQL Statements to send to Slave
- Acknowledgments from Slave
- 1 Acknowledgment that a Slave 1 received the latest SQL
- N-1 Acknowledgments from Slaves 2-N that SQL was Executed
If you have to have many Slaves, think of using a Distribution Master in a Star Topology
- Best way to setup master to multi master replication
- Is it a good idea to split MySQL DB into two servers
- Infrastructure for Highly Concurrent, High Write DB
- http://stackoverflow.com/a/5784578/491757https://stackoverflow.com/a/5784578/491757
If you cannot setup a Distribution Master in a Star Topology, then here is my simple rule: Use Semisynchrnous Replication but use as few Slaves as possible.
