RDS supports all major database platforms including SQL Server, MySQL, and Oracle. This, along with AWS Database Migration Service, makes it simple to transition from an in house database solution to one hosted with Amazon in the cloud.
The benefits of running your database platform on RDS include: lowered cost of ownership, reduced administrative burden, and improved reliability.
When your database runs on RDS all of the costs of a physical server are eliminated. No space is consumed in your data center. No electricity is used by an on site server. No wiring for data or power has to be deployed to the server.
In addition, all administrative tasks that go with patching are handled for you. No need to employ an administrator to keep on top of server and database updates. Instead, your DBA can focus on design and development of your database.
So let’s dive in and get a brief overview of RDS and some use cases to get an idea of how it can work for you. Then we’ll go through, step by step, getting up and running with RDS. We’ll close out the lesson by using RDS to improve the scalability and reliability of our WordPress website in the Extra Credit portion of this lesson.
So what’s the purpose of RDS? What makes relational databases so special?
Relational databases have formed the back-end repository for application and organizational data for decades. They have become the goto means of representing entities and the relationships between those entities. They are flexible and form the keystone of most data processing systems today.
The database backend of a system or application gives a capability of continuity and state. Transactional records, profiles, and configurations can all be stored, updated, and retrieved from the database. While similar effects can be achieved via file storage, the relational feature of these databases takes them to a new level.
Through relationships it is possible to model complex scenarios between entities. These scenarios can be used for computations during execution of the application or analysis via reporting. Secondary actions coming from either external applications or triggers within the database can generate metadata on top of the existing records to further enhance computational capability as well as reporting and analytics.
The web server example you have been working through in this course depends on a relational database backend running on MySQL. This database stores the posts, pages, configuration, and logs of your WordPress website. It models unique relationships between the data records it stores and makes it possible for WordPress to deliver the features you need from a fully functional website.
Currently the MySQL database engine that houses this database is running on the EC2 web server instance you’ve created. This works fine for small scale, single server operations. However, if you ever need to expand server capacity by adding another EC2 instance you are going to run into a problem.
If you were to clone your existing instance and spin up a second, mirror instance of the server you would start off ok. Both servers and databases would be in sync. However, as soon as you added a new post or page or any other data one of the databases would receive the update and the other would not. One version of the website would be fresh and the other stale.
That’s less than optimal.
So what to do? Not to worry. RDS is the key to solving this problem.
WordPress uses a configuration setting to point to its MySQL database backend. Currently this setting is configured to point to a local MySQL database on the same server as the WordPress website. It can easily be modified to point to a remote database on another server or in this case an RDS database instance.
In the Step by Step section of this lesson we’ll be walking through how to setup an RDS instance, migrate your WordPress MySQL database to this new instance, and configure your WordPress site to point to RDS. This exercise will enable your site to run on multiple EC2 instances and have access to the same post and page data on all of them. No stale instances.
So let’s get started.
RDS Step by Step
The RDS console is available from the AWS services drop down. Select it and you will be taken to the RDS management console.
Step One: Create a private subnet for the database
It’s important that your database be secured from direct access via the Internet. To do this we will set up a private subnet to house your database instance.
Select the VPC service from the AWS services drop down menu.
Click the Subnets link in the navigation panel.
Click the “Create Subnet” button to launch the subnet wizard. In the pop up that appears, select the VPC that you created in lesson 4.
In the “IPv4 CIDR Block” text box enter “10.0.2.0/24”. This address range should be available in your VPC as it does not overlap with the default subnet that we set up when creating the VPC.
In the availability zone drop down it is important to select an availability zone different from the subnet created in lesson 4.
Click the “Yes, Create” button.
Once this finishes you are ready for Step Two.
Step Two: Select Platform
AWS RDS offers multiple database products. The list includes.
- MS SQL
- Postgre SQL
- Maria DB
- Aurora (MySQL and Postgre SQL Compatible)
So, if you have a relational database product you are already committed to and it is on this list your transition should be smooth and simple. If you need to make a product selection you should look to how compatible each product is with your application and vendor infrastructure.
If you need help in figuring out how to compare the different solutions contact me to set up a consultation session where I can help walk you through the decision.
For our purposes we need a MySQL compatible database. I am going to use Amazon’s Aurora product. There are some clear advantages Aurora offers over traditional MySQL that you can read about on my site.
Step Three: Create an RDS Instance
From the RDS console select Aurora as the instance to launch. Make sure the MySQL compatible radio button is selected and click the “Next” button.
In the DB Instance Class drop down choose the t2.small option.
The next option, Multi-AZ deployment, allows you to specify whether or not you want a failover database setup in another availability zone. If you do choose this option it means a second database will be created and kept in sync with the primary database. If the primary database becomes unavailable for whatever reason the secondary database will be used instead.
For this course we will not be using a failover database in this course. Make sure the “No” radio button is selected.
Supply an instance name, a master user name, and a master password in the settings section. Click the “Next” button.
You will now be presented with an advanced configuration screen.
In the Virtual Private Cloud Info drop down select the VPC you created in lesson 4.
Leave the Publicly Accessible radio button set to “No” and leave the VPC Security Groups radio button set to “Create a new security group”.
In the database options section specify a database name. If you do not specify a name no database will be created.
All of the other defaults will serve our purposes for this lesson. Click the “Launch DB Instance” button.
Step Four: Review the Instance
While AWS creates the new instance you will be directed to a landing page. Click the “View DB Instance Details” button when it becomes available to see the database that was created.
In the Connect section, make note of the endpoint and port number. These will be needed to update our WordPress configuration to point to the new database.