Database Replication
Level: Beginner
Database replication is the frequent electronic copying of data from a database in one computer or server to a database in another — so that all users share the same level of information.
Basically, there are two ways to do database replication. The first one is “Master-Slave Replication”, also known as “Primary-Secondary”.
Then the next one is “Multi-Master Replication”, also known as “No-Master” or “Peer-to-Peer”.
Master-Slave Replication
In Master-Slave configuration, we have one database instance, which is designated as master or primary, there is another database instance which is designated as slave or secondary.
A client can send both read and write request to master, but can only send read request to slave instance.
The common benefit of this replication is hybrid scalability and hybrid availability. We will have one slave in our example but you can horizontally scale your read replicas over here.
How It’s work? If read operation is high in our system, our clients can actually go to any read replica and that way we can reduce the load from master database.
The sync between these two database happens through uni-directional replication, meaning any changes that are done to the master database is sent to the secondary database over time. This can be done in two ways, so first one is a asynchronous and second one is synchronous.
Asynchronous Replication:
A client writes on a database, and that transaction is immediately acknowledged once it is successful.
Later on asynchronously, that particular transaction, whatever changes that were done as part of that transaction, they are sent to the slave instance. So, there can be a time delay in this configuration.
- Low latency writes
- Eventually consistent
- Data Loss
Synchronous Replication:
On the synchronous replication when a client writes on master database, the changes are immediately sent to slave instance. That transaction is complete, when both database are in sync.
- High latency writes
- Consistent
- Low write availability
Multi-Master Replication
In Multi-Master configuration, there is no master, or we can think of both databases are master. Our clients can both read and write to any of these instance.
The replication between them is bi-directional. So If there is any change that is written on one of the database, It is sent to the other database.
Unlike Master-Slave replication, it is recommended to use asynchronous replication here. Because, there is a possibility of write conflict here. Let’s say we are modifying the same record, we reconcile the data between these two databases, then that will result in the write conflict.
Conflicts are not easy to resolve. You can write business rules and other stuff related to this to resolve write conflicts. But it’s not something that is easily achieved.
Multi-Master configuration will be useful especially if you have a region-based application. For example, let’s say we have North America and Asia PAC users. A user located in North America works on the database instance located in this region, while a user located in the Asia PAC works on the instance located in his own region. In this case, these instances will sync at the end. This will also provide fast access as we divide the data into regions.
