Join 26,000 others and follow Sean Hull on twitter @hullsean.
I once rented an apartment while traveling in Europe. Unfortunately I didn’t speak the local language of French. So when I got there I had trouble coordinating.
After about twenty minutes of frustration, I found someone who could help. They spoke some broken English. So I would speak very slowly, then they would translate. That back and forth continued, until finally we understood each other.
What would normally be effortless 5 minute process to checkin, became a thirty minute long and drawn out affair. This is essentially what managing RDS feels like. If you’re a day-to-day devops or sysadmin it can be limiting to say the least.
1. Missing command line
If you’ve been administering unix & Linux for some time, you’re using the command line. It’s the lingua franca of systems administration. There are many command line tools that help you manage a MySQL database, from top to innotop, percona-toolkit to mysqltuner. Without the command line your hands are tied. You’re left trying to breathe through a straw.
Is there a plus side to RDS? Yes of course. For those who aren’t schooled in operations, don’t manage servers 24×7, web interfaces are a godsend. They simplify things, and present a field of options to choose from. What’s more they are better dashboards for exposing management to business units.
Related: RDS or MySQL: 10 Use Cases
2. Entrusting someone to your backups
Backups are delicate piece of your infrastructure. Done wrong, and you’re missing data. What’s more when you go to recover, you need options.
Relying on Amazon’s process, means your hands are tied. Done right it will be push button simple. But done wrong and you could have a big mess.
Over the years I’ve been in a lot of fire fighting situations. Everyone is running around yelling, and looking for the extinguisher. You may want any of a number of tools at your disposal. Dumps, hotbackups, cold backups, snapshots. With RDS you’re handing over all your trust & confidence to another party for that.
Pushbutton is great if you’re not comfortable with server operations, but if you are it’s a huge limitation.
3. Can’t tweak operating system
On Linux servers, there are a number of operating system dials that can be useful to performance. One is the IO scheduler, which controls on Linux writes to disk. Another is choice of filesystem. For example you may want xfs or ext4. Furthermore there are tweaks in MySQL that can take advantage of the right filesytem, to simulate raw or unbuffered IO. These can give you a much needed bump in performance as well.
4. Slow query log limitations
Slow query log is essential. It is your most essential tool for sleuthing scalability problems.
In the early days of RDS, the slow query log file itself was not accessible. You could only use the slow query table logging, which would slow down your server. That meant you couldn’t leave it on perpetually.
Recently Amazon has made the file available, which is a step. But still you have to jump through hoops. With command line you have everything right where you need it. With RDS, you have to first download the file to your desktop, copy it to another server where you have the percona tools installed, then analyze it there. From there you have to open a mysql shell remotely to the RDS box, to run explain plan.
That is lots of hoops for an essential activity like performance tuning.
Read this: Do managers underestimate operational costs?
5. Managing parameters & security the Amazon way
Amazon has attempted to standardize management of servers. Security is managed with groups and RDS is no different. That’s great if you want all your servers setup the same way, but what if you want to tune just one server. You then have to configure multiple groups. It’s again extra steps.
MySQL systems settings are no different. As a regular daily DBA activity, you use SET GLOBAL my_parameter=my_value; But with RDS you are doing a number of obfuscated steps, through a dashboard.
Check out: Why I ask clients for a deposit