Amazon AWS Certified SysOps Administrator Associate – Databases for SysOps

1. [SAA/DVA] RDS Overview

So let’s get started with an overview of AWS RDS. RDS stands for relational database service. And what it means is that it’s a managed database service for database that use SQL as a query language. So SQL is a structured language to query a database. It’s very well adapted and it’s running on many engines. So it allows you to create databases, the RDS service in the cloud, and these databases will be managed by AWS and you get a lot of benefits from it.

So what types of database engine are managed by AWS? Well, the first one is Postgres SQL. Then we have MySQL MariaDB, Oracle, Microsoft, SQL Server and finally, Aurora. And we have a dedicated section to Aura. So right now you can just forget about it. Okay, so the first five postgres MySQL, MariaDB, Oracle and Microsoft SQL Server. You have to remember them. So why would we use RDS versus deploying our own database service on top of, say, an EC Two instance?

Because this is possible. Well, RDS is a managed service and as such, AWS provides a lot of services on top of just giving us a database. For example, the provisioning of the database is fully automated and so is the underlying operating system patching. There is continuous backups being made and you are able to restore to a specific timestamp. It’s called point in time. Restore. You can also have monitoring dashboards to view the performance of your database. You can have read Replicas, and we have a dedicated lecture on read Replicas in this course.

To improve read performance, you can set up multiaz. And so we do have also sections on multiaz that will be helpful for disaster recovery. You have maintenance windows for the upgrades, and you have scaling capabilities, both vertical by increasing the instance type and horizontal by adding read Replicas. Finally, the storage is backed by EBS. So this is something we already know, which is GP two volumes or IO One. But the only thing we do not have is we cannot SSH into the instances, the RDS instances.

So, because this is a managed service, AWS provides us a service and we don’t have access to the underlying EC Two instance. But this is not too bad because we get all these things that we would have to set up on our own if we wanted to deploy our own database engine on EC two. So let’s talk about RDS backups for a little bit.

Backups are automatically enabled in RDS and you have automated backups. They’re daily full backups of the database, which are done during the maintenance window that you define. And then the transaction logs, the daily transaction logs are backed up by RDS every five minutes. So these two things together give you the ability to restore to any point in time your database from the oldest backup all the way to what happened up to five minutes ago. There is a seven day retention of these automated backups by default, but it can be increased to 35 days and you have database snapshots.

So snapshots are slightly different from backups. Snapshots are backups that are manually triggered by the user and the backup retention. So these snapshot retention is as long as you want. So they’re more helpful if you wanted to retain the state of your database for six months at some point in time. So here is one feature that can come up in the exam and is around RDS storage Auto Scaling. So the idea is that when you create an RDS database and you say how much storage you want, for example, you want 20GB of storage, but say you are using your database a lot and you’re about to run out of free space. Then, with this feature enabled, the RDS Storage Auto scaling RDS will detect that and will scale automatically the storage for you. So you don’t have to do any kind of operations such as taking that in database to increase the storage.

So the idea is that your application does a lot of read and writes to your RDS database and then automatically with some threshold we’ll see in a second, then the storage can autoscale and that is a feature of RDS that is a very nice feature. So this all is meant to make you avoid the operation of scaling manually your database storage. For this you need to set a maximum storage threshold. So maximum limits for how much you want the storage to grow, because you don’t want it to grow infinitely maybe.

And you can automatically modify storage if the free storage is less than 10% of what has been allocated and the low storage has been lasting for more than five minutes and 6 hours have passed since the last modification. If that’s the case, then the storage will auto increase when you enable it. This is very helpful for applications with that have an unpredictable workload and this supports all database engines for Rd, just as Mario, DB, MySQL, PostgreSQL, SQL Server and Oracle. So that’s it for this lecture, I hope you liked it and I will see you in the next lecture.

2. [SAA/DVA] RDS Multi AZ vs Read Replicas

Extremely important to understand the difference between RDS read Replicas and multi AZ and understand exactly the use cases for those. So this lecture is really dedicated to understanding read Replicas and multi AZ. So let’s get started with the read Replicas. Read Replicas, as the name indicates, help you to scale your reads. So let’s have an example. Here we have our application and we have an RDS database instance. And our application performs reads and writes to our database instance. But say we want to scale the reads because that main database instance cannot scale enough. They receive too many requests. Well, we can create up to five read Replicas and they can be within the same Availability Zone, cross Availability Zone or cross region.

So three different options and they’re very important to remember. So say we have another RDS instance, we Replica and another one, and what will happen is that there will be an asynchronous replication between the main RDS database instance and the two read Replicas asynchronous that means that the reads are eventually consistent. What that means is that, for example, if your application reads from the read Replica before they had the chance to replicate the data, then you may get all data. And this is why it’s called eventually consistent Asynchronous replication. And these Replicas, they can be awesome for scaling reads, but they can also be promoted to their own database.

So you can take one of these Replicas and say, okay, I want it to be its own database now and take rights. And so you promote it to its own database. It’s completely out of the replication mechanism after that, but it lives and has its own lifecycle afterwards. So in case you want to use read Replicas, the main application in orange at the top of the screen must update the connection string to leverage the list of all the read Replicas you have in your RDS cluster. OK, very nice. So let’s talk about a classic use case for your read Replica. So in this example, we have a production database and it is taking on normal load. So here we go. Our production database is having read and writes to our main RDS database instance and a new team comes in and say we want to run some reporting and some analytics on top of your data. And so if you plug in that reporting application onto the main RDS database instance, then it’s going to overload it and possibly slow down the production application. And you don’t want that. So instead what you do as a solutions architect is you create a read Replica to run the new workload there. So you create a read Replica. There is some asynchronous replication that happens between your main RDS database instance and your read Replica.

And then your reporting application can just do reads from your read Replica and run the analytics there. The production application is completely unaffected in this case and that’s perfect. So remember, if you have a read Replica, you need to ensure that it is only for select type of statements and select is a SQL keyword. Select means read and so you cannot use keywords such as Insert, Update or Delete which change the database itself. Okay? Read Replicas is only for reads. So let’s talk about the networking cost associated with RDS read Replica. So in AWS you should know that normally there is a cost when the data goes from one Availability Zone to another but there are exceptions and these exceptions are usually for managed services. So for RDS three Replica, this is a managed service. If your read Replica is within the same region, okay, different AZ but same region, you’re not paying that fee. So what?

It means that if you have an RDS DB instance in US East one A and then a read replica in US East one B and there is a synchronous replication because this is a read replica, even though the traffic goes from one AZ to a different AZ, that replication traffic is going to be free. Because RDS is a managed service and they give you that traffic for free. But if you are using a cross region Replicas, so you are in one region, US East One and you go to another region EU West One for example, then your RDS TB instance and your root replica will have replication that will go across regions and this will incur a replication fee for your network. Finally, let’s talk about RDS multiaz.

And multiaz is mainly used for disaster recovery. So we have our application and it performs the regions rights to our Master Database instance which is in Availability Zone A. And what we’re going to have is a synchronous replication to a Standby instance in Azb and it will replicate every single change in the Master synchronously. So that means that when your application writes to the Master, that change needs to also be replicated to the Standby to be accepted. And so what we get out of it is one DNS name. So your application talks to one DNS name and in case there is a problem with the Master, there will be an automatic failover to the Standby database thanks to that one DNS name.

So thanks to this we increase the availability. This is why it’s called multiaz and there will be failover in case we lose an entire AZ or we lose the network or there is an instance or storage failure for the Master database in which case obviously the Standby database will become the new Master. You don’t need to do any manual intervention in your apps as long as it tries to keep on connecting to your database automatically at some point it will fail over to the Standby that will be promoted as the Master and you’ll be good. And it’s not used for scaling. So as you can see here, the Standby database is just for Standby no one can read to it, no one can write to it. It’s just here as a failure in case anything goes on with your master database.

So, quick question is, is there a possibility to have the read Replicas being set up as multiaz for disaster recovery? And the answer is yes, you can set up your read Replicas as a multiaz if you wanted to. And that is a common exam question. Okay, so that’s it for the difference between read Replicas and multiaz. But you need to absolutely understand this going into the exam because a lot of questions will go and be about it. So a question that can come up in the exam is around how do we make an RDS database go from single AZ to multiaz? So, what you should know is that it is a zero downtime operation. That means you do not need to stop the database to go from single AZ to multiaz.

The only thing you need to do is to click on Modify for the database and enable multiaz. That means that your RDS database instance is going to go to have a master to have a standby DB with synchronous replication without you doing anything except modifying that setting, and the database will not stop. Now, this is what the example asks you, but I want to show you what will happen behind the scenes for it to work. So, the following will happen internally.

There will be a snapshot taken by RDS automatically of your main database. And this snapshot will be restored into a new standby database. Then, once the send the database is restored, there will be synchronization established between the two database. And so therefore, the sender database will catch up to the main RDS database. And there you go, you will be in a multiag setup. So, that’s it for this lecture. I hope you liked it and I will see you in the next lecture.

• Category: Uncategorized