RDS - Amazon Web Services (AWS) Tutorial

- [Instructor] AWS's Relational Database Service or RDS can take a lot of work off your hands when it comes to relational databases. Without RDS, deploying a database to AWS can be a rather involved process. You'll provision an EC2 instance, attach storage, say using one of the services we've discussed like EBS, EFS, or FSX, and then you'll have to install and configure the database instance yourself. Patching becomes an ongoing concern both for the database and the OS it's installed on. And if you want to read replica or standby for failover, well your database platform may provide tools but you're on your own to implement them. Good news, RDS manages all of this for you. With RDS, you can select one of six different relational database platforms. Oracle, MySQL, PostgreSQL, SQL Server, MariaDB and Amazon Aurora. Let's take a brief aside to talk about Aurora. Amazon Aurora is AWS's proprietary database engine. It's compatible with MySQL and PostgreSQL and meant to outperform traditional expensive database engines. AWS advertises that Aurora provides five times the throughput of MySQL and they're positioning Aurora to compete with the likes of Oracle and SQL Server. Aurora is also highly available and durable, automatically replicating itself across three availability zones. It's even available in a serverless flavor that auto scales in response to use rather than needing to be pre-provisioned. Aurora's compatibility with existing engines means that it's an attractive migration target for organizations moving relational databases to the cloud. Back to RDS in general, when you run a database on RDS, AWS handles the compute for you. You never need to remote into an instance to manage your database processes. Of course, that doesn't mean that RDS doesn't have compute resources. Your database needs CPU and RAM to run on. With RDS, the details of the underlying compute resources are abstracted away. Under the covers is this PostgreSQL instance running on Ubuntu, Red Hat or most likely Amazon Linux? Who cares? As long as it responds on port 5432 when we want connect, we don't need to know. But we do need some control over the provisioning of the compute resource. So in a similar way to EC2, RDS provides us with DB instance classes. The instance classes of RDS mirror the naming conventions of those for EC2. Sample types include standard, memory optimized, and burst capable database instance types. Platform support varies. Some database types only support some instance classes. We can convert a database instance to another instance class whenever we like, but be aware that this will incur a reboot of the database. It's possible to reduce the outage time in a situation like this or perhaps more critically in the case of an unplanned outage. When you select multi-AZ deployment RDS will automatically synchronously replicate data to a standby instance of your database in a neighboring availability zone. Users continue to read from and write to only the primary instance, but if that one goes down, AWS will update the DNS record associated with your RDS instance and it'll resolve to the quite fresh hot standby. Some applications will still need to reconnect but the result will be much less problematic than a full blown outage. AWS claims that this failover usually occurs in under two minutes. AWS uses a variety of methods to achieve this replication. It varies based on the DB platform and its available tools. Just keep in mind that no matter the platform, synchronous replication means that every time you write you must wait for that write to replicate to the standby. If your use case can sustain the additional write latency, multi-AZ is a very attractive failover option. You can fully stop database instances giving you the same flexibility to control uptime and cost that we enjoy with EC2. Just be aware that you can only do this for seven days at a stretch before AWS will restart the instance automatically to ensure that it does not fall behind on required maintenance and patching. Another nice feature of RDS is the ability to create read replicas. Read replicas are copies of your source database that are kept up to date as changes are made in the source. RDS read replicas are kept in sync using the existing asynchronous data transfer options available in MySQL, MariaDB and PostgresSQL meaning those are the only DB platforms currently supported. That transfer is encrypted even when the replica is in another region. And since I mentioned it, yes, your replica can be in another region giving you great high availability on the chance that an entire region goes down. So why create a read replica? Well, one big reason is to reduce load on transactional systems. You can point reporting tasks or other query only workloads to the replica, ensuring your primary system remains responsive. You can create unique instances on the replica if you're using MySQL to enhance its performance without impact in the primary. Read replicas can be promoted to master manually in a scenario where the primary fails. They can be cross region, giving you additional disaster recovery assurances. And finally, your read replicate can use a different instance type than your primary, giving you more control over your cost performance ratio. One last note about replicas. MySQL can actually be replicated to Aurora since they're compatible. So even if you don't start with Aurora, you have an easy way to take advantage of its many performance and storage benefits. Back to management. Don't forget about patching. Both the underlying OS and the database engine need regular updates, some of which may be critical for security. RDS manages that too. We can choose a maintenance window, say, one hour every Sunday at midnight and RDS can automatically apply any OS patches and minor database level updates that are available for our chosen platform. No downtime unless the update does require a reboot. OS patches can be scheduled, taken immediately, or deferred, however, AWS will mark some OS updates as required and will not let them be deferred indefinitely. As for patching the database engine, well, if this capability gives you pause, fear not. AWS has considered that not all database updates are backward compatible or safe for your data. So auto patching is entirely opt-in, does not extend to "major" releases and varies based on the platform. Major updates to the DB engine you'll need to initiate yourself. You'll want to create snapshots of your data and handle any data conversion that needs to take place. Still, auto patching for minor updates can be a great time saver. It should come as no surprise that RDS gives you options as to the underlying storage of your database. Much like instance class the storage option can be changed with minimal downtime. Magnetic is the cheapest and slowest option only available for backward compatibility purposes. General purpose, scales performance with storage size. Provisioned IOPS lets you pay more to specify the performance and size you want. Finally, let's talk backup. In the same way that you can declare a maintenance window for RDS, you can declare a backup window. By default, RDS creates and keeps seven days worth of daily backups for you. But that can go up to 32. Even better, RDS can restore not only any of those daily backups but by replaying transaction logs, it can restore to any point in time within the backup window down to the minute. You should know that anytime you restore an RDS instance you're not restoring in place, RDS will spawn a new RDS instance using the backup point that you request. So if you need to restore some data into your hot copy you'll still need to either manually restore data or reconfigure apps to point to the restored database. Now let's head into the console and try our hand at creating an RDS instance.