The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including AWS Certified Database - Specialty Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.

Amazon RDS and Aurora

18. RDS Multi-AZ deployments and read replicas

In this lecture, let's look at the multi-AZ deployments in RDS. So, multi-AZ deployments provide you with high availability, and it also helps with data durability and fault tolerance. And with RDS, you don't use multi-AZ deployments for scaling purposes because the second instance in the multi-AZ deployments is a standby instance that does not take active reads and writes. So here you can see that your application reads and writes to the master database instance in one of the availability zones. When you enable multi-AZ deployment, AWS creates another RDS instance in a different availability zone and performs synchronous replication to the standby instance over low-latency links. So this instance is a passive instance; it does not take active reads or writes. And whenever there is an outage, there will be an automatic failover to the standby instance. The standby instance will only become active when the master instance fails for some reason or goes down. And both of these instances have the same DNS names. Whenever the Master goes down, RDS simply points the standby instance to the DNS name. And remember that this automatic failover can happen in cases of planned as well as unplanned outages. So if you have a maintenance window going on, you could see an automatic failover happening from your master RDS instance to the standby instance. And whenever RDS upgrades the database instances, it first upgrades the standby server and then the master fails over to the standby, and then the master gets upgraded. And as I mentioned, RDS uses DNS routing to point to the new master. So you don't have to update your database connection strings when the failure happens. And the failure times are typically between 60 and 120 seconds, so this is kind of minimal downtime. Now, failure times refer to RTO, and RTO is recovery time objective, and it refers to the amount of time your database takes to recover from any system failure or outage. And whenever RDS takes automated backups, these are always taken from the standby instance instead of the primary. And hence, RDS can ensure high performance levels during the backup activity. As a result, it is recommended to use multi-AZ configurations whenever your use case necessitates backups. And of course, for production use cases, you should always use multi-AC, so that's a given. And RDS also provides you with an option to simulate AC failures. The way you do it is to reboot the master instance and choose the option to reboot with failover. So when you choose the option to reboot with failover, the master instance will be rebooted and the standby instance will become active in that process. Let's take a look at the RDS replicas or RDS read replicas now. Here we have the application talking to the database instance. The database instance, the Master instance, takes all the reads and writes, so you can always create a read replica of the Master. So this is like a read-only copy of your Master Database instance. This will help you to segregate your web traffic. So if you have very heavy workloads, you can definitely consider creating replicas of your master database instance. And you can create up to five read Replicas.These can be within AZ, cross-AZ, or cross-region as well. So the way it works is that it's just a copy of your Master Database instance. You can create up to five copies, as I mentioned. and this is an asynchronous replication. Unlike the multi-AZ deployments, which provide synchronous replication, this is asynchronous replication. So there will be some replication lag when you're using asynchronous replication. And that's why we say that the reads are eventually consistent. All right? So the read replicas, of course, as the name suggests, only support read operations. Write operations will still happen on the MasterDatabase instance, and your applications must update the connection string to use the read replicas. Now, read replicas will have their own endpoint, which you can use to read from those replicas. And definitely, replicas boost the database's performance and durability as you have another copy of your data. And your reads are separated across instances. So it's useful for reading-heavy workloads, as I mentioned. And a good thing about replicas is that you can promote these replicas to primary instances. So it does complement the multi-AZ deployments. Just remember that the promotion, or read-replica, to primary is a manual process. It is not an automatic process, okay? And remember, when you want to create a replica, you must enable automated backups. If you have disabled your backups by setting the retention period to zero, then you will not be able to create a replica. You must enable automatic backups if you want to create a replica of your database instance. And another important thing to note here is that, just like the master database instance, replicas can also be deployed in a multi-AZ setup. So Replica can have its own standby instance, just like the Master instance. Let me show you what I mean. So you have your Master Database Instance, which takes reads and writes. And you have your read Replicawhich takes only read operations. All right? And then there is asynchronous replication between the master and the read replica. And if you enable multi-at for the master instance, then there will be a standby instance in another AZ, and there will be synchronous replication between the master and its standby instance. And there will be a common DNS name for automatic failover. And if you enable multi-AZ for the read replica, then you will have a standby for your read replica in another AZ, which is in an AZ that is different from the AZ of the read replica. And there will be synchronous replication from the replica to its standby. And of course, there will be a common DNS name between the replica and its standby. So both the master and the replica can have their own standby instances. So this is a multi-AZ setup for replicas as well. So this kind of complements the automatic failover. just like the master. If the read replica goes down, then the read replica standby will be automatically failed over to, and that will become the new read replica for your database. Set up and read replicas, as multi-AZ is supported for MySQL, MariaDB, DB2, Postgres, SQL, and Oracle. And this does work as Dr target. So when promoted to primary, it will work as a multi-AZ. Okay.

19. Read replica use cases

Now, let's look at the use case for reading replicas. So let's say you have a production database that's taking on a normal load. So an RDS instance takes, reads, and writes. And let's say you want to run another application, a reporting application, to run some analytics. So reporting applications typically only need to read data. They don't write data to the database. So you can create a read replica, and you can use that read replica to cater to the load coming in from the reporting applications. OK, so the production application remains unaffected, and your reporting application is served through the read replica. So read replicas are typically only used for read operations, that is, select operations. They do not support the right operations or operations like insert, update, and delete.

20. Promoting a read replica to a standalone DB instance

Now, let's see how to promote aread replica read replica to its own standalone database instance. instance. So you have a mastermaster and two replicasreplicas here, here, and there will be asynchronous replication, of course. course. And let's say you choose to promoteone of one of the replicasreplicas to a standalonestandalone instance. instance. Then the promotedpromoted instance is rebooted andand becomes an independent database instance. instance. Now, once it is promoted,it is it is detached from its mastermaster instance. instance. So it now acts as a standalone database instance. Okay? Okay? So it will no longer work as a replica. replica. And this does not affect the behaviourbehaviour ofofother replicas other replicas of the original database instance. instance. All right? right? And of course, the new instance thata standalone a standalone database can have its own replica replica So you can create replicasreplicasfor that for that instance later as well. well. And remember that you cannot promote a replicareplicato a to a standalone instance while a backup operation is running. running. So that's something you should remember. remember. Now, let's look at the use cases. cases. Now, you can use this processas a as a Dr strategy for disaster recovery. recovery. And another use case is to avoidthe performance penalty the performance penalty of DDL operations like rebuilding indexes. indexes. So let's say you wantto perform to perform DDL operations on your tables. tables. By DDL, I mean data definition. Language. Language. Or in other words, you want to changechangethe table the table structures or the tabletable schema. schema. So one way of doing it isto perform to perform these DDL operations on a replicareplica insteadinstead of doing that on the mastermaster instance. instance. And then once those changes have been mademade, youyou can point your app to this new instance. instance. So you can make this new instance your new primary. primary. And you can use thatnew instance new instance with the new tabletable structures. structures. And remember, by default,read replicas read replicas only take read operations. operations. They do not support write operations. operations. And you can actually make your replicasreplicaswriteable by writeable by setting the read-onlyread-only parameter to zero. zero. Okay, so this is a nifty thing to know. know. And the third use case is shutting down. shutting down. So you can split a large databaseinto multiple into multiple smaller databases by creating multiple readreplicas and replicas and promoting them to stand-alonestand-alone instances. instances. And once these databases are standalone, then youcan choose can choose which data to keep in which database. database. One database will have one set of data. data. A secondA second set of data can be in the second one. one. So this way,way, you cansplit the split the large database into smaller databases. databases. So this is kind of a shade. shade. And you control it at the application level. level. As a result, your application understands where to write which data. As a result, your application understands where to write which data.

21. RDS Multi-AZ failover and replica promotion – Demo

Alright, in this demo, I'm going to demonstrate how failovers work in a RDS multi-AZ setup. So here I have my SQL database running on RDS. So I have a Master instance and a replica of that Master instance. Both the master instance and the read replica have their own standby instances in another AZ. All right? And as you can see, both the master and the replica are multilingual. So if you click on the Master instance and go to the Configuration tab here as well, you can see that multi-AZ is enabled and the secondary zone is US East to see.And of course the primary region andAZ is US East to A. Similarly, if you look at the replica, you can see that the primary region is US East 2, the AZ is US East 2 B, there are multiple AZ, and the secondary AZ is US East 2 C. All right? So the master has a standby instance, and the read replica also has its own standby instance. So if we trigger a failover, then the instance is going to fail over to the standby, and it's not going to fail over to the read replica. And remember that RDS supports automatic failovers, and when failover occurs, the instance fails over to the standby instance. And this is true in case of Master aswell as in case of the read Replica. So let's see that in action. So I have the Master instance selected, and let's look at what options we have in the Actions menu. So here we can see that we have the option to reboot the instance. Similarly, if we look at the options for reading Replica, you will see the same set of options there as well. So you can see an option to promote Replica here. So if you promote the read Replica, then readReplica is going to be a new Master. And remember that promoting to a "read replica" in RDS is a manual process. There is no automatic failover to a replica in the case of RDS. So the first thing I'm going to demonstrate is I'm going to go to the master instance and choose to reboot it. We can see an option to reboot with failure here. Let's select that and reboot. Remember that our master is in Azure East two A, and when we reboot it with failure, it is going to fail over to the standby instance, which is, I believe, in US East two C. All right? So let's reboot and see how it goes. And you can see that the current region is US East (to A), and when the failure completes, this region should change to US East (to A). So now you can see that the status is rebooting. So this is going to take a while. So I'm going to pause the video here and come back once this process is complete. Alright? Alright, so now you can see that the instance is available again. but we don't see any change in the region or in AZ. The reason for this is that failovers do not immediately reflect in the RDS console; it might take a few minutes I'll return in a few minutes to see if the AZchanges in the console here are correct. All right. So now you can see that the master is now in the region, or in the Azure East, to see that the failure is complete, and it's reflecting in the RDS console as well. So if you go into the master, you can see that the primary region now is US East 2 C and the secondary zone is US East 2 A, so whenever you perform a reboot with a failover, the instance will failover to its standby in another easy and not to the Replica sonow let's see what happens if we fail over a Replica.So this replica is in the US East to BE availability zone, and its secondary zone is US East to C, so when we fail over, The US East to C will be the primary zone, and the US East to B will be the secondary one right.And if we go to the Connectivity and Security tab and scroll down, you can see that the replication source for this read replica is the Database Master instance, and the status is replicating, so I'm going to reboot the read replica with failover now. So now the replica should failover to its own standby just like the master instance, alright? So this is going to take a while, and I'll be back once this process is complete. Now that you can see that the replica is available, it's going to take a while for the new zone to reflect in the RDS console. Let's pause again for a bit, and I'll be back once this change reflects here, all right. And now you can see that the new AZ is showing uphere so our read Replica is now in US East to Seeregion so if you go into the red Replica you can seethat the primary region and AZ is now US East to Cand the secondary region is now US East to B and ifwe switch over to the Connectivity and Security tab and scroll downto the replication section you can see that the replication source isDatabase Master and replication state is Replicating so now the Database Masteris Replicating to the failed over Replica that is in Zone USEast to See. Return to the database screen once more. Now, let's look at how to promote a read replica to be a standalone instance, which you do by selecting the read replica and then selecting the option to promote from the Actions menu, so you can see additional preferences to configure your backups for the promoted instance. so you can choose as per your preferences and continue. And here is where you'll be asked if you're certain you want to promote this read replica. And remember, when you promote a Read Replica, this Read Replica is going to become a standalone database instance and is no longer going to be replicating data from its original master. And this process cannot be undone. All right? So you should remember this. And once you're sure, you can click on the Promote Read Replica option to promote this Read Replica to be a standalone instance. However, I'm not going to do that. I'm simply going to cancel out of this and go back to the database screen. And if you read this information here, it does say that before you promote this read replica, we recommend you stop any transactions on the master and wait for the read replica lag to be zero. Otherwise there is a high likelihood that the read replica does not have all the transactions committed to the master TB instance. And also remember that the promotion process takes a few minutes. So when you promote a Read Replica, replication is stopped, and the Read Replica will be rebooted as part of this process. And this process is irreversible. So you cannot restart the replication once you make your replica a standalone database instance. Alright, but I'm not going to go ahead with this promotion. I'm going to cancel out and go back to the database screen because I want to show you something else that's as interesting. All right? So let's go back to the database screen. What I'm going to do is I'm going to select this master instance, and I'm going to delete it. So can you guess what happens when the Master Instance gets deleted? So when I delete the Master, its standby instance is also going to be deleted. Deletion of the master is not going to result in failover to the standby instance; instead, both the master and the standby instance are going to be deleted. And remember that this Master is the replication source for the Read Replica. After deletion, the Read Replica is no longer going to have a replication source. The Read Replica will become a standalone instance. So it will be promoted to be a standalone instance. Let's go ahead and see that in action. So let's go ahead and delete the Master instance. I'm not interested in the snapshot, so I'm going to acknowledge the deletion, confirm the deletion by typing deleteme in this field, and go ahead with the deletion. And this process is going to take a while, so I'll come back once this Master instance gets deleted. So now you can see that the Master is being deleted. And as the master gets deleted, you will see the role of the replica getting changed.And now you can see that the master instance is deleted. And the read replica is in the modifying status, and if you look at the role of this replica, the role has been changed from reader to instance, which indicates that the read replica is now a standalone instance. So I'm going to pause the video here and come back in a few minutes, and now you can see that the read replica is available and is no longer a reader. Replica is a standalone instance, so let's go into this instance and look at its configurations so we can see the region. The primary region and AZ are both US East, and if we go to the configuration tab, we can see that the secondary region is also US East. And if we look at the replication section in the Connectivity and Security tab here, you can see that the instance role is instance, and there is no replication here, so that confirms that this instance is now a standalone database instance, right? And now since we are done with the demo, I'm going to go ahead and delete this database instance, alright? So that's about this demo, and I'll see you in the next lecture, alright?

22. Enabling writes on a read replica

Now we'll look at how to enable writes on a read replica. Now, we just discussed it a moment ago, so the way you do it is with your first-stop rights on the replication source that is the master instance. And then in the case of my sequel or Mariah DBread Replica, you simply set the read-only parameter to zero, and that will make that read-only Replica write able.Okay, so you simply set the read-only parameter to zero, and TADA! Your replica is now written. And now that your read replica is written, you can perform DDL operations on it without affecting the source database. And remember, actions that you take on a read replica don't affect the performance of the source DD instance. And once you have completed your DDL operations, you can then promote the read replica to a stand-alone database. Alright.