Introduction
A read replica is a read-only copy of a DB system within the same region as the DB system. Read replicas provide you read scalability and you can offload all read-heavy workloads to the read replicas. Read replicas have the same shape and configuration as the associated DB system, and can exist only within a DB system.
MySQL Database Service supports read replicas for all types of DB systems: Standalone, HeatWave, and High Availability. You can create a maximum of 18 read replicas of a DB system, and in case the DB system is not delete protected, you can choose to delete the read replicas anytime.
Asynchronous Replication and Read Replica Lag
When you create a read replica, MySQL Database Service takes a snapshot of the associated DB system and creates the read replica. When you want to update data, the data is first updated in the associated DB system. After that, the data is replicated to all read replicas. This method of replication is called asynchronous replication.
The delay in updating the read replica is called read replica lag. The read replica lag is dependent on the workload and the shape of the DB system.
Read Replica Load Balancer
A read replica load balancer helps to distribute read traffic among the read replicas. When you create the first read replica, a read replica load balancer is created automatically, and all read replicas are added as a backend to the load balancer. If the read replica load balancer is not created for any reason, then the read replica is not created either. A read replica load balancer is deleted only when you delete the associated DB system.
Placement
Let us now see how the read replicas are placed when the region contains single or multi-availability domains.
Case 1: Single availability domain
If the region you are subscribed to contains only one availability domain, then the read replicas are placed across fault domains. Creating the read replicas in different fault domains protects them against unexpected hardware failures or planned infrastructure maintenance.
Let us assume the DB system resides on the fault domain, FD1. The first read replica you create resides on the same fault domain as the DB system – in this case, FD1. The second replica that you create resides on the next fault domain, FD2, while the third replica resides on the fault domain, FD3. If you create a fourth read replica, it is created in FD1, and this cycle repeats until you have reached the maximum number of read replicas you can create for a DB system.
Case 2: Multi-availability domains
If the region you are subscribed to contains multi-availability domains, then the read replicas are placed across availability domains. The fault domain in each availability domain is determined automatically, and you do not need to select it. Creating read replicas in different availability domains provides you high availability and disaster recovery alternatives.
Let us assume the DB system resides on the availability domain, AD1. The first read replica you create resides on the same availability domain as the DB system – in this case, AD1. The second replica that you create resides on the next availability domain, AD2, while the third read replica resides on availability domain, AD3. If you create a fourth read replica, it is created in AD1, and this cycle repeats until you have reached the maximum number of read replicas you can create for a DB system.
Connecting to a Read Replica or a Read Replica Load Balancer
Read replicas and read replica load balancer have private endpoints, that is, they have private IP addresses, and you cannot access them directly from the internet. You can connect to the read replicas and read replica load balancer in a similar way as you connect to a DB system – using Cloud Shell, compute instance, bastion session, or VPN. For more information, see Connecting to a DB System.
Read replicas and the read replica load balancer are present in the same private subnet as the DB system. Hence ensure you have added the ingress rules to the virtual cloud network correctly. For more information, see Adding Ingress Rules.
Maintenance
The maintenance of a DB system involves a very short period of downtime. There is no impact on the downtime if you add read replicas to a DB system.
The automatic upgrade, which starts during the maintenance window of the DB system, is handled in the following manner:
- Standalone DB systems: The read replicas are upgraded in parallel with the DB system.
- High availability DB systems: The read replicas are upgraded one by one, followed by an upgrade in the secondary DB system, and finally the primary DB system is upgraded.
Current Limitations
- Read replicas are present in the same region as the DB system and you cannot move it to another region.
- You cannot promote a read replica to a separate DB system.
- To create a read replica, the shape of the DB system should have 4 or more OCPUs.
Benefits
- Scalability: Read replicas scale out a DB system beyond its capacity to handle read-heavy workloads. By creating multiple read replicas of a DB system, you can increase aggregate read throughput.
- Performance: You can reduce the load on the associated DB system by redirecting read-heavy workloads from applications to the read replica. You can utilize the associated DB system for time-sensitive read/write operations and increase write throughout.
- Delete Protection: You can protect the read replica and its associated DB system against delete operations by enabling the Delete Protect feature.
- Cost-effective: The read replicas are charged on similar lines as the other resources in a DB system. Read replicas turn out a cost-effective solution because instead of purchasing a larger shape for the DB system, you can create read replicas and offload the read-heavy workloads to the read replica.
- Security: The data present in the read replicas are encrypted. Also, when the data is replicated from the associated DB system, in-transit encryption is used.
Summary
If you wish to increase scalability and performance of the DB system, take advantage of the read replicas. MySQL Database Service completely manages read replicas and the read replica load balancer and they are easy to set up. Read MySQL Database Service Documentation to understand how to create and manage a read replica.