Read Replicas ¶
- A
multi-AZ instancecan not be promoted to a read-replica. - There is no charge for primary-to-secondary data replication.
- Although it’s not particularly common, you can set up a read replica in an on-premises instance. Additionally, read replicas are often created in separate regions from the primary instance, to improve performance for clients closer to different regions than the primary instance.
- Currently, read replicas in RDS are only supported by MariaDB, MySQL, and PostgreSQL. Not for DynamoDB
- Read replicas are updated via asynchronous replication— the most performant approach.
- Read replica setup only allows for five read replicas. This is not a limit that can be raised by AWS.
- Read replica has its own database engine active so that it can be promoted to a primary DB.
Promoting Read Replica¶
The read replica maintains a secure asynchronous link between itself and the primary database. At this point, read-only traffic can be directed to the read replica to serve queries, perhaps on business intelligence tools.
By implementing read replicas, it helps to offload this traffic from the primary instance, and therefore, helping with the overall performance.
Remember
Do be aware when thinking about deploying read replicas that they are only available for MySQL, MariaDB, and PostgreSQL database engines. However, for the latest supported engines for read replicas, it is always best to consult the AWS documentation, as this can change over time. Thankfully, it is possible to deploy more than one read replica for a primary database, and there are a number of different reasons as to why you might want to do this.
By adding more than one read replica, it allows you to scale your read performance to a wider range of tools and applications that need to query the data without being restricted to a single read replica. It is also possible to deploy a read replica in a different region, which significantly helps to enhance your DR capabilities.
It's also possible to promote an existing read replica to replace the primary database in the event of an incident (as shown in the below diagram). Also, during any maintenance that is being perform on your primary instance where I/O requests may have been suspended, then read traffic can still be served by a read replica.
Tip
- Multi-AZ setup is focused on disaster recovery and fault tolerance, while read replicas provide performance and scalability.
- You can manually promote (not automatically ) a read replica instance to a stand-alone instance if you have to.
- Read replicas do not create automatic backups, but the primary database instance must have automatic backups enabled to create read replicas.
- There is no particular performance increase in a Multi-AZ deployment unless read replicas are also turned on.