Scaling MySQL Master‑Slave Replication with Binlog Server: Architecture, Benefits, and Use Cases

The article introduces the challenges faced by Booking.com when a single MySQL master serves dozens to over a hundred replicas, causing network bandwidth saturation, especially during large transactions or online schema changes.

Traditional solutions use relay masters, which introduce latency and single points of failure. The authors propose a Binlog Server that downloads binary logs from the master, stores them with identical filenames, and serves them to replicas as if it were a secondary master.

Key benefits of the Binlog Server include:

Elimination of bandwidth bottlenecks when scaling beyond 50 replicas.

Avoidance of cascade‑replication drawbacks.

Simplified disaster recovery and faster promotion of replicas to new masters.

Reduced replication delay because the Binlog Server does not generate its own data changes.

Several deployment topologies are described:

Replacing relay masters with Binlog Servers in a single data center.

Using Binlog Servers to avoid deep nested replication across remote sites.

Combining multiple Binlog Servers for high availability, allowing automatic failover between them.

High‑availability designs with dozens of replicas directly connected to the master via Binlog Servers.

The article also outlines practical steps for handling master failures, re‑pointing replicas to alternative Binlog Servers, and re‑building the replication tree using GTID positions.

In conclusion, introducing a Binlog Server enables horizontal scaling of MySQL replicas without exceeding network limits and mitigates the disadvantages of traditional cascade replication, while also supporting remote‑site replication and topology re‑organization after failures.