The course is part of these learning paths
When to use RDS Multi-AZ & Read Replicas
Learn when to use RDS Multi-AZ and Read Replicas with this concise course from Cloud Academy. In this course, you will be able to uncover the reasons behind RDS multi-AZ and will come away with being able to know when to implement and use this feature within your own environment.
Understanding how this works is essential for you and your team as understanding the differences between Read Replicas and Multi-AZ’s is key when trying to design a resilient and performance optimized RDS database.
This short course is made up of two informative lectures along with a cohesive summary. If you would like to discover more content related to this subject matter, you will find all the related training content below.
- Explain the differences between Multi-AZ instances and Read Replicas.
- Understand the different techniques and methods used to implement Multi-AZ across different DB engines.
- Recognize the limitations and subtle differences between Read Replicas across different DB engine types.
- Those who are responsible for maintaining and managing RDS databases within AWS.
- Solution architects wishing to take the AWS Certified Developer - Associate certification.
- An understanding of Amazon RDS, including how to set up an RDS database within a single availability zone.
- Be familiar with AWS global infrastructure, regarding regions and availability zones. More information on this can be found in this blog post.
Related Training Content
- [Instructor] Hello, and welcome to this final chapter, where I want to provide a high-level overview of some of the key points made throughout the previous lectures. I started this course by looking at RDS Multi-AZ, and within this lecture, I explained that Multi-AZ simply means Multi Availability Zone. And it's a feature that is used to help with resilience and business continuity. Multi-AZ configures a secondary RDS instance, known as a replica, within a different availability zone within the same Region as the primary instance. The only purpose of Multi-AZ is to provide a failover option for a primary RDS instance. Replication between the primary RDS database and the secondary instance happens synchronously.
RDS uses a Failover mechanism for Multi-AZ's deployment when using Oracle, MySQL, MariaDb and Postgres instances. Failover happens automatically, and is managed by AWS. RDS will update the DNS record to point to the secondary instance, and take between 60 to 120 seconds to complete. RDS Failover triggers and event, RDS-EVENT-0025, when the failover process is complete. SQL Server Multi-AZ is achieved through the use of SQL Server Mirroring, which is supported on limited versions. SQL Mirroring provisions a secondary RDS instance in a separate AZ than that of the primary RDS instance to help with resilience and fault tolerance. Both primary and secondary instances in SQL Server mirroring use the same Endpoint. A DB subnet group must be configured with a minimum of two different AZ's within it, and to check which AZ the standby instance is in, you can use the AWS CLI command of describe-db-instances.
By default Amazon Aurora DB clusters are fault tolerant, and Aurora can automatically provision and launch a new primary instance in the event of a failure, which can take up to 10 minutes. If you enable Multi AZ on an Aurora cluster, it allows RDS to automatically provision a replica within a different AZ. Should a failure occur, the replica instance is promoted to the new primary instance without having to wait 10 minutes, creating a highly invaluable and resilient database solution. In the chapter following Multi-AZ, I looked at Read Replicas, and how these provided a very different function to the RDS databases. Here I discussed the following points. Read Replicas are not used for resiliency. Read Replicas are used to serve read-only access to your database data via a separate instance. Read Replicas maintain a secure asynchronous link between itself and the primary database. By implementing Read Replicas, it helps to offload read traffic from the primary instance.
Read Replicas are only available for MySQL, MariaDB, and Postgres database engines. You can deploy more than one Read Replica for a primary database, and you can promote an existent Read Replica to replace the primary database in the event of an incident. The retention value of the automatic backups of the primary DB needs to be set to a value of one or more, for all Read Replicas in all database engines. For MySQL, Read Replicas are only supported where the source DB is running MySQL 5.6 or later, and replication is also only possible when using an InnoDB storage engine, which is transactional, as opposed to MyISAM, which is non-transactional. MySQL and MariaDB allow for nested Read Replicas, and Amazon Cloudwatch can monitor the synchronization between the source database and the Read Replica through a metric known as ReplicaLag. When using MariaDB, any version can be used for the source database for Read Replicas.
When using Postgres, you need to run version 9.3.5 or later for Read Replicas. The native Postgres streaming replication is used to handle the replication and creation of the Read Replica, and a role is used to manage replication when using Postgres. Postgres also allows you to create a Multi-AZ Read Replica instance, however it does not allow nested Read Replicas. That now brings me to the end of this lecture, and to the end of this course. You should now have a greater understanding of Amazon RDS Multi-AZ and Read Replicas, how they differ, and how they can be used within your environment to both create additional resilience and to help with database performance. If you have any feedback on this course, positive or negative, please contact us by sending an email to firstname.lastname@example.org. Your feedback is greatly appreciated. Thank you for your time, and good luck with your continued learning of Cloud Computing. Thank you.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data centre and network infrastructure design, to cloud architecture and implementation.
To date Stuart has created over 40 courses relating to Cloud, most within the AWS category with a heavy focus on security and compliance
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.