Amazon RDS and Aurora

23. RDS read replica capabilities

Now let's quickly discuss the replication capabilities in RDS. So you can create multiple readreplicas in quick succession. You can use a DB snapshot to perform PIT on a read replica, so you can really do point-in-time recovery of a read replica using a DB snapshot. And a good thing to know is that you can actually create a replica from an existing replica. What I mean by this is, let's say you have a master instance and you have a rate replica. Then you can create another replica from this first replica. So the first replica is the first tier replica, and the second replica is the replica of the first replica. So the first tier replica is the replication target for the master database, and the second tier replica is the replication target for the first tier replica. So it kind of frees up your master database instance from the replication load and that load is passed on to the first year replica, right? So remember that the lag, or replication lag, will be higher for the second year replica because it will have to wait for the replication to happen on the first year replica first. And only after the first year replica has new data will it be able to replicate it on the second tier replica, so there will be higher application on the second year replica. So if you can live with the additional replication lag, then it's definitely a good idea to create a second replica every year to reduce the replication load from the master instance. Alright.

24. RDS Second-tier replicas and replica promotion – Demo

Alright, in this demo, we're going to look at the first tier and second tier replicas. So here I have a My Sequel database running on RDS and we have a master instance. And I have created three replicas. Out of these, two are first-year replicas. The sand one is a second-year replica. So here you can see that the first year replica two is a replica of the Master. And the first year replica is also a replica of the Master. And in addition to this, it also acts as a source or the replication source for the second tier replica. So the second tier replica is replicating from this particular replica, so it's not replicating from the master. If we click on the Master instance and scroll down to the replication section, you can see that the replication source for the first year replica One and first year replica Two is database One, which is the Master. While the replication source for the second year replica is the first year replica One, the Master is acting as a source for the two first year replicas, whereas the first year replica One is acting as the replication source for the second year replica here. And one important thing to remember here is that you must enable backups on those instances when you want to create any replicas. For example, if you look at the configuration of your Master instance in the Maintenance and Backups tab,you will see that the backups are enabled here. all right? Similarly, if you go to the first tier replica, which is acting as the replication source, you will see that for that replica as well, I have enabled the backups, and by default, the backups are disabled on any read replica. So anytime you create a read replica,the backups will be disabled by default. So you must modify your read replica and enable backups if you want to create a second tier replica that's replicating from a particular replica. all right? And if you look at the first year replica, you can see that backups are disabled. So if you try to create a replica of this particular replica, you can see that the "Create Read Replica" option is disabled. But for this particular replica, which has the backups enabled,you can see that this option is enabled and you can create a read replica from this replica. This is all about the first and second year replicas. And now I'm going to show you what happens when you delete the master instance in this particular scenario. So it's fairly easy to guess what happens. So when we delete the master, what's going to happen is that this particular replica,which does not have any second tier replica, will become a standalone database instance. And this particular replica, which has a second-tier replica, will also become a standalone instance,but it's going to act as a master. And this second-tier replica will become a first-tier replica and will continue to replicate like its master. So let's see that in action. I'm going to go ahead and delete the master instance. I'm not interested in any snapshots. I'm going to uncheck that, acknowledge the deletion, and type in delete me and delete. And now we can see the master instance is being deleted. And now, as expected, you can see that the role of the first tier replica has changed to Master. The role of the second-tier replica remains as an areplica, but it will now be a first-year replica. And the first year replica has now become an instance. It will act as a standalone instance. Initially, we had one master with three replicas, one database cluster with three replicas, and one master. But now we have two stand-alone database clusters. The first cluster is the combination of the first-year replica one and second-year replica one. So one is the master and one is a replica. And the first-year replica, Twois, is now a standalone instance. And you can verify this by looking into the instance configuration. So let's go into the first year replica one and scroll down to the replication section, and you'll see that the replica one is the master. The replica is the second-tier replica one, and it is replicating from the master. So now this is a first-tier replica. And going back, if you click on the first replica two and scroll down to the replication section, you'll see that it's a stand-alone instance and there is no replication happening on this particular replica. All right, and remember, whenever you want to create a read replica, the replication source or the instance that is acting as the replication source must have a nonzero backup retention period. Or in other words, it must have automatic backups enabled. Alright, so that's about this demo. Let's continue to the next lecture.

25. Cross-region read replicas in RDS

Now let's look at crossregion read replicas in RDS. So, what this simply means is that you can place your replicas in different regions. And this is supported for Mariah DB, MySQL, Oracle, and Postgres SQL.It's not supported for SQL Server. So how does this help? Crossregion read replicas simply means that your doctor's capability is improved, right? So if your region goes down, you can still have your data in another region, and you can always promote that replica in another region to be the new primary. all right? And you can, of course, scale the operations closer to your end users. Your end users will get data faster if you have a global user base. There are some limitations of crossregion Replicas.For example, there will be higher replicataion times because region-to-regional replication will be slower than in-region replication. AWS does not guarantee more than five cross-region replica instances. That's the kind of limit you have. You can only have up to five clicks across region replicas with any RDS database. Alright.

26. RDS replicas with an external database

This is kind of a nifty feature because you can create a read replica of any external database. Let's say you have your database sitting in your on-premise data center. You can actually create a read-only replica of that instance as well. So this is a replication between an external database and an RDS replica. This is supported for the MySQL and MariaDB engines. You can have your MySQL or MariaDB database sitting in your on-premise data center, and you can actually create a replica in the AWS cloud using the Arduous Replica. The way you do that is you simply copy the source database using MySQL dump or MySQL import and copy the data into the RDS replica. Or another way is that you can create a backup of S three using Per Kona extra backup. This is a tool that you can use to create a backup into S3, and then you can restore that data from S3 into your RDS Replica. And once you've done that, then you can start your application using your bin log replication. So you can either use bin log replication,or you could also use GTID-based applications. Okay? So when you use Bin log replication or binarylog file position replication, these are the commands. So what you do is you use this command called "MySQLRDS set External Master" and then you start the replication. So what this simply means is you create an aReplica with an external master, and when you're using GTID based replication, the syntax is a little different. So what you do is you call Mysequel RDS Set External Master with auto position. So this is the way you can create RDS Replicas with an external database. Alright?

27. RDS disaster recovery strategies

Now let's discuss the disaster recovery strategies in RDS. Dr strategies are important and essential to ensure business continuity despite unexpected failures or outage events. Now, with RDS, yes, we do have multiAZ, but multiAZ by itself is not enough because it can't protect from logical TVcorruption or from malicious attacks, for example. So if the data in your master instance gets corrupted, the standby instance data is also going to get corrupted. Multi-AC will not be able to protect you from logical DB corruption issues or from malicious attack issues. As a result, multi AZ is insufficient on its own. We have to have a disaster recovery plan and there are two key metrics that are part of any Dr plan: the RTO and RPO. So what are these terms? RTO stands for Recovery Time Objective. And RPO stands for Recovery Point Objective. All right, so let's look at the RTO. Now, RTO. Is recovery time an objective? So you have a disaster and then there will be some downtime before your database becomes operational again. So the amount of downtime you have is the RTO. RTO measures your downtime. So, the length of time it takes to recover from a disaster is determined by your RTO and is generally expressed in our OK. And the RPO, or the Recovery Point objective, is used to measure the amount of data loss. So, RPO is the amount of data loss you experience because of a disaster. So how much data you're likely to lose if there is a disaster is an indication of your RPO. So RPO indicates how much data you could lose after a disaster. It's also expressed in hours. So for example, RPO 1 hour means you could lose an hour's worth of data. All right, so these are the two key metrics in any doctor's plan. Because RDS writes logs to S three every five minutes, an RDS pitr pointing to time recovery provides an RPO of five minutes. So the maximum amount of data loss you could have is about five minutes. So with RDS PR, you get an RPO of five minutes. All right, now let's compare the strategies available in RDS. So here are three strategies: You can have automated backups, you can use manual snapshots, and you can also have read replicas for Dr. purposes. When it comes to recovery time objective,that is the amount of downtime. Reap replicas give you the best RPO, which means the least downtime, and they also give you the best RPO. That is, there is a minimal data loss because they use asynchronous replication. So you're hardly going to lose any data in case of a disaster. At the same time, the cost of read replicas is going to be high because for each replica you pay the same price that you would pay for any database instance. So if you use two replicas and one master instance, you're going to pay for three instances. So that is three times the cost of replicas. They support cross-regional disaster recovery. Manual snapshots also support cross-region recovery,while automated snapshots can only be used in a single region. Of course, you can copy the automated snapshots into a manual snapshot and then do a crossregion recovery. All right, so you can go through this table and understand the RTO and RPO implications of different doctor strategies. And remember, when you use replicas,there is a certain replica lag. So that is the amount of time that the replicas are behind the source database that is going to indicate your RPO or the amount of data loss. So that's going to be in milliseconds,I believe, most of the time. And replica lag can impact your recovery. And another important thing that you have to remember is that failover to anRDS read replica is a manual process. It's not an automated process. So you have to manually failover to the RDS read replica. So if your master instance goes down, replicas are not going to be automatically promoted. And a good DR plan should always include a combination of all these options. You should have backup replicas as well as multi-AZ and multi-region deployments. So that's how a good DR plan is created.

ExamSnap's Amazon AWS Certified Database - Specialty Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Amazon AWS Certified Database - Specialty Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.