Deployment and Provisioning
In this group of lectures we run a hands on deployment of the next iteration of the Pizza Time solution. The Pizza Time business has been a success. It needs to support more customers and wants to expand to meet a global market.
We define our new solution, then walk through a hands on deployment that extends our scalability, availability and fault tolerance.
Hi, and welcome to this lecture.
In this lecture we'll talk about managing RDS data. We'll talk about point in time backups, and you're going to talk about RDS snapshots. Then you're going to have a demo on how to manage RDS snapshots.
We already talked about a lot of things in regards to RDS, we talked about reader replicas, we talked about Multi-AZ databases, we talked about cross-region redirectors and you can use all that stuff to manage your RDS data. So I will not talk about the things that we already talked about, instead I will talk about point in time backups, and snapshots.
So RDS automatically creates a storage volume snapshot of your DB instance, and you can define a backup retention period for those snapshots. If you remember when you are creating an RDS database, we have this option and we can set some keystone values in this option.
We can set values between 0, that we will not retain any backups, and 35 days. Also with these automated backups, you can restore your DB instance to any specific time during this retention period. This is called point in time backups, and something that is important for you to know, all automated backups are deleted, and cannot be recovered when you delete a DB instance. So if you might recall from our RDS deployment lecture, when we deleted the database that we created in the first lecture of this course, AWS asked us if we wanted to generate a snapshot, 'cause all automated backups are deleted when we delete a DB instance. So it is important to keep that in mind, and if you want to keep that data, you need to take a final snapshot of your DB instance.
Let's go to the AWS console, and learn how to manage RDS snapshots. I'm already at the RDS console, and in here let's go into Instances page. I will not show you the whole process of restoring a point in time backup, but this is very simple, and you probably know what to do when you need to do this. You just need to select the instance that you want to restore, and you go in Instance Actions, and you have in here Restore to Point in Time.
And in here you have a page very similar to the other pages, similar to the page where you can create a new database, similar to the page where you can create a replica, and similar to the page where you can migrate your database. So this is the same page that we have been using for the whole course, and the only difference in here is that you can Use the Latest Restorable Time, or you can define a Custom Restore Time, and that will create a new database.
You can notice that you need to specify a new DB Instance Identifier, and after you click on Launch DB Instance, you create a new database with the point in time data that you want. I won't talk about point in time backups in this demo, instead I will talk about RDS snapshots.
So in here we have two snapshots. One was automatically created for the new database that we created using Amazon Aurora, and we have also the migration snapshot that we took from the MYSQL database that you created in the first lecture of this course. And with snapshots, we have a few options.
We can restore this snapshot, which will create a new database with the same engine that we have been using.
We can migrate the snapshot to in our AutoDatabase.
You can copy the snapshot, that will copy the snapshot to another region, so you can select the region where you want to copy this snapshot, and you can simply copy the snapshot.
You can share the snapshot, this is useful if you want to launch a new DB instance in another AWS account, using this snapshot so you can share the snapshot.
And of course, you have the option to delete the snapshot.
So talking real quick about cross-region replication, you can configure cross-region replication for backup purposes, and disaster recovery purposes, but maybe sometimes your business can handle a bigger downtime, and you don't want a read replica running all the time in another region. So what you can do is you can take regular snapshots from your database, and you can copy them to another region, and by doing that you can create a disaster recovery strategy.
You'll be able to launch your database in a different region but that will take some time, but for a few business cases that will be just okay.
About the Author
Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.