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 support@cloudacademy.com. Your feedback is greatly appreciated. Thank you for your time, and good luck with your continued learning of Cloud Computing. Thank you.