There has been plenty of hype about Amazon RDS for hosting databases on the internet. It can be confusing at first—and even after you’ve been using it for a while. If this is all new and strange to you, and you’re thinking about moving your database to Amazon RDS, there are many things to consider. Here are ten things you ought to know before you take the leap.
Many people worry that Amazon may not have the expertise for upgrading and maintaining patched versions of MySQL. Even if that was true, Amazon has enough resources and money to justify buying what they need from other vendors with the required expertise. Their patch for version 5.1.38 of MySQL enables it to scale dynamically in the Cloud, besides adding other features.
Amazon RDS DB instances are basically instances of MySQL running on an EC2 platform. Persistent storage, which is used for back-ups and other such things, is allocated in EBS volumes. However, you can neither access the underlying EC2 instance, nor can you use S3 to access your stored database snapshots. Taking it a step further, since you don’t get access to the native EC2 instance, you can’t install additional software on the MySQL host. This means that you can’t use an agent-based monitoring tool. So consider this before investing in one.
If you want to modify the my.cnf or my.ini file, you can’t. Amazon doesn’t give you direct access to the MySQL configuration file. Instead, it provides an API that you can use to make changes (see DB Parameter Groups).
Amazon requires you to schedule a regular, weekly 4-hour maintenance window within which the management system will roll out patches for MySQL, back up your data, and perform other such maintenance. If you don’t set the day and starting time that you prefer, they’ll set it for you. Amazon may never need the entire four hours. It may be only minutes where backups are concerned. Still, it could sometimes result in an unacceptable amount of downtime for your database.
This feature is by far the most convenient. Your entire database can be backed up to snapshots-on-demand. With the Automatic Backup feature, Amazon promises point-in-time recovery up to the last five minutes. Be aware, though, that snapshots add to your storage and can result in extra charges if you keep too many of them and exceed what’s been allocated to your account.
Replication in MySQL may be a little unstable, and human intervention may be required occasionally to recover crashed slaves. So disabling replication may be fine for some to ensure high availability of your database server. Nevertheless, replication can be useful for scaling out read operations, as well as making back-ups without any downtime. It would be nice to have replication.
Given that Amazon promises point-in-time recovery up to the last five minutes, the binary log must be enabled. Regardless, you’re not given access to the binary logs, and you can’t use tools such as the mysqlbinlog for other purposes. That can be frustrating.
Amazon does not grant SUPER and SHUTDOWN privileges even to the master user of the database instance. The primary reason for not permitting SUPER is because they’re blocking direct access to the MySQL configuration. Not permitting SHUTDOWN relates to security: being able to take the server off-line can involve acute security threats.
Although you’re not given SUPER privilege, you can still use the SET statement to change session variables. For most, this is all that is needed. Additionally, the WITH GRANT OPTION privilege is given to the administrator so you that you can add users and grant them privileges.
An inherent drawback of all cloud-based systems is network latency. When you’re located a continent or so away from Amazon’s Cloud data center, you can expect delayed transmission of data. Add to this intra-cloud network latency and network-attached storage latency, and you have a significant slowing of services. This depends largely of course on the quality, stability, and speed of your Internet connection. There seems to be no reason, though, to question the quality of Amazon’s Internet connection.
Amazon won’t install a monitoring agent on their server for you. But Monyog provides unique monitoring capabilities that allow you to monitor your MySQL database on Amazon with ease. For more OS specific counters, however, you will have to rely on Amazon’s CloudWatch. Amazon RDS provides the following metrics to CloudWatch to compensate for not providing SSH access to the underlying EC2 instance:
CloudWatch, though, costs extra. That’s yet another reason why you should use instead a remote monitoring tool like Monyog.
The most important factor of which you should be aware is how the charges are calculated. Be very care regarding this. If you decide to set up a database instance with which to experiment and to learn about Amazon RDS, but never use it, you will still be billed as long as it’s running. Even if there is absolutely no activity on the server, if you let it run for a week, this could result in a bill of one or two hundred dollars. So be careful even when you’re just trying features. Be sure to remove anything you don’t need. And make sure you understand how your bill will be calculated for the things you need before you go too far.