Replication Formats

Master-Replica architecture is one the most common high-level architectural pattern prevalent in distributed systems. We can find it in use across databases, brokers, and custom-built storage engines.

So, when we are employing a Master-Replica pattern to improve availability, throughput, and fault-tolerance, the big question that pops up is how the writes happening on the Master propagates to the Replica. In this essay, we will talk about exactly this and find out about Replication Formats.

Write Propagation

Once the write operation is successful on the Master node, the changes must be propagated to all the Replicas. This is done via a log known as Replication Log, Commit Log, or Binary Log. Once the write on the Master is successful, an event is recorded in this Log file; and this file is then pulled by the Replicas.

Once the Replica gets this log file, it goes through the events and starts applying the necessary changes on its copy of the data. This way, it continuously follows the changes happening on the Master node. The time elapsed between the write operation on the Master and the operation taking effect to the Replica is called Replication Lag.

Now that we have a solid understanding of Write Propagation, we focus on the primary agenda of this essay, Replication Format, and talk about how these formats share the entire Replication process.

Replication Formats

Any write operation happening on the Master is logged in the Replication log file as an event. The format in which these events are logged in the Log file is called Replication Format. The two Replication formats that are widely used across distributed data stores are Statement-based and Row-based formats.

Statement-based Format

In Statement-based format, the Master node records the operation as an event in its log, and when the Replica reads this log, it executes the same operation on its copy of data. This way, the operation on the Master node is executed on the Replica, which keeps it in sync with the Master.

Say the Client fires an operation on the Master to bulk update all the 5 tasks of a user to be marked as done. The operation fired by the Client on the Master node would look something like this.

  UPDATE tasks SET is_done = true WHERE user_id = 53;

When the write operation is completed on the Master, this exact operation is recorded as an event in the Replication Log file. When the Replica reads this log file, the node executes this operation and updates the same 5 tasks on its own copy of the data.

statement based replication


The events recorded in the Replication Log are the actual operations that happen on the Master. Hence, the log files take up the bare minimum storage space required. It will not matter if the operation affects one row or thousand; it will be recorded as one event in the Log file.

Another great benefit of this format is that it can be used to audit the operations on the database because we are recording the operations verbatim in the Log file.


The biggest and the most significant disadvantage of the Statement-based format show up when the non-deterministic operations are fired on the Master. The operations such as UUID(), RAND(), NOW(), etc, generate value depending on factors that are not under our control. When these operations fire on the Replica, they might generate values different from the value they yielded on the Master, leading to data corruption.

Since the Replica node, apart from replicating from the Master, is also actively handling requests, some locks might be taken on some of its entities by the executing queries. When a conflicting query is fired from the replication thread, it could result in unpredictable deadlock or stalls.

Row-based Format

In Row-based format, the Master node logs the updates on the individual data item instead of the operation. So the entry made in the Log file would indicate how the data has changed on the Master. Hence, when the Replica reads this log, it updates its copy of the data by applying the changes on its data items. This way, the operation on the Master node happens on the Replica, and the Replica nodes remain in sync with the Master.

Say the Client fires an operation on the Master to bulk update all the 5 tasks of a user to be marked as done. The operation fired by the Client on the Master node would look something like this.

  UPDATE tasks SET is_done = true WHERE user_id = 53;

In the row-based format, instead of recording the operation, the Master node records the updates made on the data items. Since the operation in question updated 5 rows, the events recorded in the Replication Log file would contain 5 entries, one for each data item changed and would look something similar to

tasks:121 is_done=true
tasks:142 is_done=true
tasks:643 is_done=true
tasks:713 is_done=true
tasks:862 is_done=true

Hence, one operation on the Master is fanned out as series of updates on the data items and is consumed by the Replica. The Replica then reads these events and applies the changes on its copy of the data.

row based replication


The major advantage of the Row-based format is that all the changes can be safely and predictably applied on the Replica. This approach is safe even with the non-deterministic operations because what gets written is the computed value.


When the Master node completes the operation, it takes the lock on the Replication Log file and then records the events. Since the number of events recorded in the log file will be the number of data items changed, the lock taken by the Master node will be longer, choking the throughput.

Another obvious disadvantage in this approach is fan-out. If an operation changes 5000 data items, it will result in 5000 events in the Log file, and if such operations are frequent, this will make Logfile take a lot of storage space.

Arpit Bhayani

Arpit's Newsletter

CS newsletter for the curious engineers

❤️ by 38000+ readers

If you like what you read subscribe you can always subscribe to my newsletter and get the post delivered straight to your inbox. I write essays on various engineering topics and share it through my weekly newsletter.

Other essays that you might like

Multi-Master Replication

497 reads 2021-11-03

In this essay, we look at what Multi-Master Replication is, the core challenge it addresses, use-cases we can find this ...

Handling outages in a Master-Replica setup

375 reads 2021-09-07

This essay talks about the worse - nodes going down - impact, recovery, and real-world practices....

Replication Strategies

821 reads 2021-08-10

In this essay, we take a quick yet verbose look into Synchronous, Asynchronous, and Semisynchronous replication strategi...

The RUM Conjecture

670 reads 2020-05-31

While designing any storage system the three main aspects we optimize for are Reads, Updates, and auxiliary Memory. RUM ...

Be a better engineer

A set of courses designed to make you a better engineer and excel at your career; no-fluff, pure engineering.

Paid Courses

System Design for Beginners

A masterclass that helps early engineers and product managers become great at designing scalable systems.

180+ learners

Details →

System Design Masterclass

A masterclass that helps you become great at designing scalable, fault-tolerant, and highly available systems.

1000+ learners

Details →

Redis Internals

Learn internals of Redis by re-implementing some of the core features in Golang.

98+ learners

Details →

Free Courses

Designing Microservices

A free playlist to help you understand Microservices and their high-level patterns in depth.

823+ learners

Details →

GitHub Outage Dissections

A free playlist to help you learn core engineering from outages that happened at GitHub.

651+ learners

Details →

Hash Table Internals

A free playlist to help you understand the internal workings and construction of Hash Tables.

1027+ learners

Details →

BitTorrent Internals

A free playlist to help you understand the algorithms and strategies that power P2P networks and BitTorrent.

692+ learners

Details →