High Availability in RDS
Designing for high availability, fault tolerance and cost efficiency
Business Continuity and Disaster Recovery for SAP on AWS
The course is part of this learning path
** Not all content covered in the course introduction has been added to the course at this time. Additional content is scheduled to be added to this course in the future. **
In this section of the AWS Certified: SAP on AWS Specialty learning path, we introduce you to strategies for configuring high availability and disaster recovery for SAP workloads on AWS.
- Understand how to configure high availability with Amazon RDS
- Identify backup and disaster recovery strategies using the AWS Cloud
- Describe various approaches for business continuity and diaster recovery for SAP workloads on AWS
The AWS Certified: SAP on AWS Specialty certification has been designed for anyone who has experience managing and operating SAP workloads. Ideally you’ll also have some exposure to the design and implementation of SAP workloads on AWS, including migrating these workloads from on-premises environments. Many exam questions will require a solutions architect level of knowledge for many AWS services. All of the AWS Cloud concepts introduced in this course will be explained and reinforced from the ground up.
Hello, and welcome to this lecture that is going to focus on the first of the database services that I'll be looking at in this course, that being the Amazon Relational Database Service commonly known as RDS. Let me examine the different methods of performing a backup of RDS databases first.
When you are looking into backup your RDS database, you effectively have three different options or methods of doing so involving both automatic and manual procedures. Firstly RDS offers the ability to provide automatic backups of your RDS instance. Notice I said instance and not just the RDS database table itself. Secondly, you can perform a manual backup using snapshots. And lastly, you can use the AWS backup service to also create a backup of your RDS database. And even though you're using an AWS managed service in this case which can automate backups for you using AWS backup, it is still considered a manual backup from an RDS perspective.
Let me look at each of these methods in more detail, starting with RDS automated backups. As with most automation within AWS, automated backups offers a level of assurance that the task is going to be completed and removes the unreliability of the human nature in people to perform the backup themselves.
When configuring your automatic backups for your RDS database, you have a number of different parameters to apply to the automatic backup settings, such as retention period, and the backup window as seen here. The automated backups themselves are performed daily and the backup retention period determines how long RDS will keep and maintain your backups for, and this can be set between zero and 35 days.
For automatic backups to take place, the retention period must be set to at least one day. If the retention is set to zero, then automatic backups will not take place. If you create your database using the AWS CLI, then a default retention period of one day will be configured. Whereas if using a console, the default is seven days.
The backup window allows you to define a time period in which the backup snapshots should be taken. And this allows you to set it at a time when the database itself will be of low utilization to prevent the backup process impacting the performance of the database itself.
During the first few seconds of the automatic backup process, your storage IO might temporarily be stopped. However, if you're using a Multi-AZ configuration, then the backup will not affect your storage IO as the backup will be taken from the standby instance for the database and not the primary.
For more information on Multi-AZ configurations please see our existing course here. If the backup fails to complete inside the time window you specified, the backup will extend past the timeframe to ensure it completes. However, you must ensure that any backup window that you schedule does not overlap with the maintenance window that you configure for your database.
Failure to select your own backup window will result in AWS scheduling its own 30-minute time period based across an eight-hour window. And this window is depending on which region you are deploying your RDS database in. And all window times are based on the UTC time zone.
Once the configuration is complete and your RDS database is being backed up, you are able to restore back to any point in time during retention period, known as point-in-time-recovery. And I'll cover more on this when we come to looking at restoring your RDS database.
As a part of the automated daily backup process, RDS also captures any transaction logs that have been created as, and when updates to your database was made. And this is to ensure that it can perform a point-in-time recovery. If you're curious as to where these backups are stored, RDS automatically stores them on Amazon S3. And so they remain highly available and highly durable.
You can also see from the screenshot that it states automated snapshots are only supported for the InnoDB storage engine and not MyISAM. This is because MyISAM does not support reliable crash recovery which could result in corruption when trying to perform a point-in-time-recovery. Whereas InnoDB is a crash-recoverable storage engine.
So now we have all of these automated backups. What happens when you delete your database? What happens to the automated backups then? When you delete your database instance you'll be given the option to perform a final database snapshot. By doing so you'll be able to restore your database to the configuration of that instance at that point, if needed at a later stage.
When you delete your database instance you can retain your automated backups if you are running MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL server engines. But they'll only last as long as the retention period would allow them to. So they will eventually expire.
So as a result, if you want to maintain a backup to restore from at a later stage, then ensure you select to create that final database backup when prompted before deleting your instance as this will not automatically expire. Also, if you have created any manual backups snapshots these will also be retained.
So let me talk more about the manual backups, which, as I mentioned earlier, is the second method of backing up your RDSdatabase. In addition to the automatic backups that I just explained and discussed you can also create your own user-initiated manual backups known as database snapshots these snapshots back up your database instance in the state at the time of the backup. They do not offer the ability to perform point-in-time recovery, instead, the database will be restored to how it was at the point in time the backup was taken.
When you create your first backup, a full backup is taken capturing the whole database instance. Any subsequent backups that are taken of the same database instance, then an incremental backup will be taken. And this means that only the data that has changed since the last backup will be backed up. And this helps to save on storage space.
Unlike automated backups, database snapshots are not restricted by any retention periods. As a result, your database snapshots will remain for as long as required without expiration until you explicitly delete them.
Let's now look at how you create a database snapshot for an RDS database, which is a very simple process from within the AWS management console. However it can also be accomplished via the createDBSnapshot API, or via the AWS CLI command online using create-db-snapshot.
Okay, so I'm logged into the AWS management console as you can see, and I'm within the RDS dashboard. Now under databases, I have a single instance here. Now to create a manual snapshot of this database, all I need to do is to ensure that I have the database selected, then go across to actions and down to take snapshot. Now, here I can enter the snapshot name, so I can just call this Mysnapshot. And then I just need to go across to take snapshot.
Now, as we can see, the snapshot is in the status of creating, it has the snapshot name and the instance that the snapshot was taken off. And remember, these manual snapshots will create a backup of the database as it stands right now.
Okay, that's completed. We can now say the status is showing as available. And you can scroll along to see other values of this snapshot as well, for example, the engine that was used, the VPC, the storage, the availability zone, etc, etc. And you can select the snapshot to get additional information too.
Down here under recent events, it will show you the time that the snapshot was being created and also when the snapshot had been successfully created. So it's very simple and easy to create a manual snapshot of your database. Now, if you wanted to do this using the command line and we can do this by using a simple command, let's take a look.
So the command I need to type in is aws rds create-db-snapshot. Then I need to enter the database snapshot identifier. And this will be the name of the snapshot. So I'm just gonna call this CLISnapshot. I then need to enter the name of the database instance identifier. And this is the name of the database instance that I want to create a snapshot from.
So if we go back to the console to double check that we can see that it's my-db-instance. So what this command will do it'll create a database snapshot using this as the name of the snapshot and it will take this from this database instance. And then we go, that snapshot is now created. So if we go back to the management console and look under our snapshots we should see this new name of clisnapshot. Let's take a look.
So if we go cross to our snapshots. And there we have it, the clisnapshot. And as you see at the moment, the status is currently creating. So it's very easy to create a manual snapshot either through the AWS management console or using the AWS CLI. As I mentioned at the beginning of this lecture, you can also use AWS backup to perform the backup of your RDS databases which are classed as manual backups like the database snapshot that we just created.
For those unfamiliar with AWS backup, AWS backup acts as a central hub to manage backups across your environment, across multiple regions, centralizing management and providing full audit capabilities in addition to assisting with specific compliance controls.
Having a managed service to monitor and control your backups allows for all logins to be consolidated in a single place. In addition to seeing the status of completed backups and perform any restores required. The service itself uses backup features from existing services. So for example, when using AWS backup with RDS, AWS backup would manage these through the database snapshot functionality as we did previously.
When using AWS backup you will need to create backup policies or backup plans, and they simply determine the exact requirements that you need for your backups. Once you've created your backup plans you can then assign resources to them. And this allows you to create multiple backup plans each with different criteria to meet the backup needs of different types of resources.
At the time of writing this course, AWS backup supports all database engines, other than Aurora. However, this would likely change over time. So be sure to check with the AWS documentation for all supported database engines.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.