MySQL Slave Scaling (and more)

At Booking.com, we have very wide replication topologies. It is not uncommon to have more than fifty (and sometimes more than a hundred) slaves replicating from the same master. When reaching this number of slaves, one must be careful not to saturate the network interface of the master. A solution exists but it has its weaknesses. We came up with an alternative approach that better fits our needs: the Binlog Server. We think that the Binlog Server can also be used to simplify disaster recovery and to ease promoting a slave as a new master after failure. Read on for more details.

Photo by Viktor Jakovlev on Unsplash
Figure # 1: Replication Tree with many Slaves.
Figure # 2: Replication Tree with Intermediate Masters.

Other use-case: avoiding deep nested replication on remote sites

Figure # 3: Remote Site Deployment with an Intermediate Master.
Figure # 4: Remote Site Deployment without Intermediate Master.
Figure # 5: Remote Side Deployment with a Binlog Server.
Figure # 6: Remote Site Deployment with two Binlog Servers.

Other use-case: easy high availability

Figure # 7: Replication Tree with 6 Slaves.
Figure # 8: Replication Tree with a Binlog Server.
Figure # 9: Replication Tree with many Binlog Servers.
Figure # 10: Converging Slaves after the Failure of the Master.

Conclusion

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store