Note-
Recommended to read PART-3.
Introduction
In part-3, we scaled the web-tier to resolve failover issue by scaling ‘horizontally’ the web-servers, thereby adding multiple servers. For data-tier, we have one database which will use to store website data. Single database does not have failover. In case this database is compromised/fails, critical website user data will be lost. How do we ensure database failover and redundancy?
Redundancy means duplicating the database so that if the main database fails, there is a backup.
Difference between redundancy and failover is that —
– Redundancy : using two components when one would be sufficient. The redundant component is there in case the main component fails.
– Failover : the automatic transfer of workload from a failed component to another component.
(Component here can be a server or a database)
Data-Tier Failover and Redundancy Strategy
One simple strategy to prevent data loss in case of fault, is to replicate the data across multiple databases. This is called ‘Database Replication’.
Database Replication
Replicating data into multiple databases ensures failover and redundancy.
But the question is that if we have more than one database, how does the web server know which database to read/write data?
To solve this, we follow the Master-Slave database strategy.
According to this strategy
- If we have “N” databases, we will assign one database as the ‘Master’ database where only write operations will happen and
- “N-1” databases will be slave databases, where only read operations will happen.
When a web server is supposed to write on the database it will invoke the master database and if it needs to read the data, it will invoke one of the slave databases. The master database eventually replicates the data across the slave databases to maintain consistency. See diagram below —
How does above strategy handle failure (failover strategy)?
The obvious question we asked when we introduced load balancer in web-tier is that if one of the server failed, how will we handle it, there the solution was to distribute the traffic of the failed server on to the rest of the servers. Here we ask the same question, if one of the databases fail, what will we do?
To answer that, let’s consider two cases —
- Slave Database fails — In case a slave database fails, read operation can still be done by rest of the slaves and the incoming web-server read requests to this failed database will be transferred to other slaves.
- Master Database fails — In case a master database fails, we can simply promote a slave database as the master database and perform write operations on that. When the failed database is back again, it can be then used as slave database.
In this way failover is ensured when any one of the database fails. So by now, we have successfully created a web-tier and data-tier both and ensured failover so that there is no outage and also our system is able to handle sufficient load (multiple requests).
See you in part-5, where we will talk about improving the response time of the application/service and storing static content outside database (Hint: CDN).