Earlier quoted context omitted.
Disagree with what? Keeping your own backups? Probably not - if you're not keeping offsite backups, you're begging to go out of business. With needing a DBA, even if you're still on RDS? I don't see what that has to do with PCI compliance. With RDS only removing the up-front setup pain, at the cost of ongoing maintenance... as someone who is also familiar with PCI (and HIPPA, and DOD) compliance, I respectfully disag…
> Disagree with what? I disagree with the notion that RDS removes remarkably little of the pain of running a database instance. Yes, there are projects where RDS is not a great solution, but it definitely simplifies a lot of stuff. The notion that it "only removes up-front setup pain" is silly. If you manage your databases correctly, up-front setup pain should be the vast majority of all your basic admin operations.…
Let's look at a common problem that DBAs are typically given: "The Database is slow!". Let's troubleshoot this ficticous problem on RDS:
Am I being affected by a noisy neighbor? Can't tell; contact Amazon support.
Can I look at top to see if the load is high on the box, and potentially why? No. I can look at historical trends, but not with enough granularity or information to be useful.
Can I look at the disk iops to see if there's any kind of problem there? No. Complete black box here; contact Amazon support.
Can I look at the slow log? Kind of. They'll push the slow log data into the database for you to query, but then you can't use tools to do aggregate tracking.
Pause for a moment for a quick MySQL RDS tip: pt-query-digest has a mode of operation that lets you do a processlist every 1/100th of a second and turn that into a pseudo slow log, which does work for RDS.
pt-query-digest --processlist h=10.0.0.1 --interval=0.01 --output slowlog > /tmp/fake_slowlog.out
Can I kill queries? Yes, using a stored procedure. Can't use any of the existing toolset around this (like pt-kill, which can help keep poorly written ad-hoc queries from getting out of hand).
So, after many hours swapping emails with Amazon support, we've determined that we're actually spending a lot of time waiting on malloc mutexes. The internet says that using a non-default version of malloc will help with that - can I do that?
Nope. You're stuck.
Other things you can't do:
* Offsite backups that are in any form but MySQL dumps.
* Take advantage of new index types and compression support from TokuDB.
* Zero downtime failovers (We were able to help someone fake this; it was a PITA).
* Cross-region replication.
* Automated failovers using a reputable tool (MMM, MHA, etc).
* Access the error logs.
* Run multiple instances on one machine.
* Alter the disk elevator (hopefully they're using something sane, like noop, but we'll never know)
* Alter the kernel swappiness.
* Troubleshoot crashes.
* Monitor and alert on a machine's vitals.
Now perhaps I'm just being a power-hungry admin, but these small things matter. They are the difference between a snappy DB which scales beautifully to 10,000+ QPS, and a sluggish DB that causes you to move to bigger hardware, because it's the only option open to you.
Databases just aren't that hard to set up. Install packages, install config files, start the DB, restore from a backup file, restart the DB, and you're golden. If you're particularly paranoid, set up the selinux contexts (I'd bet dollars to doughnuts that this isn't done on RDS instances), and create a security group that limits access to only the 22 and 3306 ports to your application hosts, and set up individual users.
This is particularly simple when you use an orchestration tool; I recommend Ansible personally.