Well, if you have been following along with my DBaaS series you know that we are slowly getting through the different services I mentioned in the first article. Up this week is Amazon Web Services' (AWS) RDS offering. Out of all of the offerings we will go over I think it's easy to say that Amazon's offering is by far the most mature offering, namely due to the fact that it was released way back in 2009 (December 29th), and has a long history of regular release upgrades.
For AWS I didnt do the performance testing like I did last time with Google's offering because lately I've also been working on a demo site for a local IT group, so I thought why not migrate the local MySQL database that I had on my web server to the AWS offering and leave the apache services local on that server (so just a remote database instead of local). So as I go through things and you see the screenshots that is what I was trying to get working.
CREATING AN AWS SQL DATABASE
It's pretty obvious that AWS has been doing this a while. The process for creating a new database instance is very straight forward. We start by pickign what type of database, for the purposes of my project (Wordpress) I need RDS as it offers MySQL.
Next we select the engine type we want to use, in this case I am picking MySQL then I click Select.
The next thing AWS wants to know is if this is a production database that requires multiple availability zones and / or a provisioned amount of IOPS.
Then we get to the meat of the config.
Everyhting is pretty much the same as the other offerings, fill out the name of your instance, pick how much horse power you want and then put in some credentials.
The advanced settings step lets you pick what VPC you put your DB instance into. VPC's seem to be popping up more and more in the different use cases I've ran into for AWS. For this purposes I just left it as the default as I dont currently have any other VPC's.
Lastly on the Advanced Settings step you also can select how often automatic backups and maintenance windows take place. Then click Launch DB Instance to get started.
One of the things that I should have pointed out a while ago, but didn't because I assume everyone knew, is that DBaaS instances are basically just standard virtual machines that run inside of your account. The only thing that is different is that there are some more advanced control panel integration into that DBaaS VM.
OK so after a few minutes we can refresh the dashboard and see our new MySQL instance.
There you go! that's all there is to creating
CONNECTING TO YOUR AWS SQL DATABASE
So now that we have our database server created we can connect to it, but there is a catch. AWS uses firewall rules that block everything except the WAN IP address of where you created the instance from. So the first thing we need to do is go create a proper rule if your WAN IP isnt the same as where you will be connecting from. (So for my example my Home IP was auto white listed, but the web server that wil be connecting to the database is at a colo, so i needed to allow the colo IP to connect)
So create new firewall rules you will want to navigate over to the VPC Security Groups area and find the Security Group rule that was created for your DB instance. At the bottom you see an Inbound Rules tab and there is where you can edit the inbound rules to include the proper IP... In my case its the 184.108.40.206 IP.
Once we have that rule in place I can login to the web server and try to connect via the MySQL command line client to verify.
In my example I already had wordpress installed and running and I just wanted to migrate the database to AWS. So what I did was use mysqldump on the local web server to dump wordpress to a .sql file. Then from the command line I ran the cilent again, this time telling it to import the SQL database into the AWS MySQL instance.
This was a new site so it didnt take long at all.
Once that was all done I simply edited my wordpress config file to point at the endpoint displayed on teh instance dashboard along with the username and password I setup previously and it worked on the first try!
Monitoring your database instance is super easy. Amazon has Cloudwatch, a monitoring platform build in, which can send you emails or other alerts once you setup some triggers. Cloudwatch also provides some nice graphs that show pretty much anything you could want to do.
Here is another shot. This one monitors the actual VM underneath the DBaaS layer.
BACKUP/RESTORE AND REPLICATION
So Backup is pretty easy ... you configured it when you created your instance. Optionally you can also click Instance Actions and then pick Take Snapshot to manually take a point in time snap.
Restores are pretty much just as easy. Like with the other providers you arent really restoring the database so much as you are creating another Database insance at that point in time. To do that there is a "Restore to point in time" option in the instance actions... Which is a little misleadinig since you arent really restoring... oh well.
If you need some geo-redundancy you can also create a read replica, which can later be promoted to the active instance should the primary fail. The wizard to do so looks very much like all the other wizards. THe only real difference is the "source" field, where you pick which database instance you want to make a replica of.
SO WHAT DID YOU THINK?
I know what I think... experience matters. The simple fact that AWS has been doing this basically forever in terms of "cloud" and "as a service" technology, means that they have had a lot of time to work out the bugs and really polish the service.
And to be real honest I wanted to do a post about the HP Helion service this week... However the service is still in beta, and while testing it out I hit a snag which actually put a halt on tests. Ill share more about my experience with HP support next time in the article about their service.
Until next time!