Features I am missing on Amazon RDS
Great service Amazon RDS.
It’s on my to-do list to evaluate it from a performance-wise perspective. The evaluation is a must as AWS is known to have steady but slow storage performance, I wonder if the RDS team did tweak their volumes.
But this is not the subject of the post:the fact is, there are two and a half points, at first examination, that need to be worked out before I prefer it to my own-built MySQL AMI.
SSL or SSH connections are missing:
Can’t use clear-text connections for on-premise or on-line mash-ups, it’s too easy to intercept them.
RDS’ MySQL has SSL built-in but it seems Amazon decided to start the instance without the –ssl xxx options:
mysql> SHOW VARIABLES LIKE 'have_ssl'; +---------------+----------+ | Variable_name | Value | +---------------+----------+ | have_ssl | DISABLED | +---------------+----------+ 1 row in set (0.11 sec)
SSH is not enabled: one has no control over the instance running MySQL and relative services. No tunneling available thus.
For the sake of clarity: I am looking for encrypted communications only, of course authentication might be attainable too.
No way to configure BinLogs
Even if RDS is a managed service, we need, sometimes, the ability to tinker with BinLogs. The administrative user that Amazon provdes has no way to interact with BinLogs.
mysql> select @@sql_log_bin; +---------------+ | @@sql_log_bin | +---------------+ | 1 | +---------------+ 1 row in set (0.11 sec) mysql> set @@sql_log_bin = 0; ERROR 1227 (42000): Access denied; you need the SUPER privilege for this operation
No NDB engine
Ok, this is not really a “plain-vanilla” feature but it would be welcome.
I am not talking of implementing clusters, something that Amazon has in their roadmap.
For some Web architectures speed is crucial and it would be nice to keep tables in memory because you want to maintain DB security or you ust don’t want to add another moving part: Memcached in this case.
A table can be pinned in memory using the TYPE = MEMORY switch but it’s just for temporary data and does not support row level locking. One update ad the whole table is locked.
A technique documented by Yves Truedau here uses NDB to allow use of full-featured tables in-memory. A single host NDB would manage that very good.
Am I suggesting not to use Memcached? No, but, as Yves rightly point it out, sometimes security it’s a concern and Memcached is exposed.
