Hacker News Reader

Comment by blantonl | Hacker News Reader

Amazon's new MySQL "cloud" MySQL service looks very positive on the surface, but there are a number of things that will need to be addressed before serious production use for large sites can leverage this offerings. They are:

1) Replication. Very very few large production Web sites run with one database server. The need to dynamically scale replicas and slave servers is critical for many Web applications.

2) Lock in to InnoDB tables. From what I've seen you can only run InnoDB tables. For some, MyISAM is a requirement, and in some cases provides better query performance.

These two issues right here are why I continue to run my MySQL server infrastructure myself in EC2. If and when they address those two critical components I'll most certainly give the new offering a hard look.

View on HN

I don't think you're locked into InnoDB tables, just that seems to be the default. I've just set up an instance and imported my MyISAM tables across and they all seem to be working ok.

That is good to hear. From what I read in the docs it appears that only InnoDB tables were supported.

Amazon says replication is "coming soon":

"High Availability Offering — For developers and business who want additional resilience beyond the automated backups provided by Amazon RDS at no additional charge. With the high availability offer, developers and business can easily and cost-effectively provision synchronously replicated DB Instances in multiple availability zones (AZ’s), to protect against failure within a single location."

Amazon's 'replication' is not mysql replication though, it is a drbd block level replication and can not be used for scaling reads like normal mysql slaves can be used.

Why can't DRBD be used for scaling reads?

It can but you will not have access to the secondary drbd'd system on the rds service, it is strictly for ha and not for read scaling.

The app I've been working on doesn't use replicas for read scaling, just cache-money (ergo, activerecord). We're partitioning for write scaling but no slaves (well, we're doing master/master replication but not for read capacity).

After having had to contend with replication lag, lots of instances spinning and related headaches for years I'm pretty convinced that scaling reads with binlogs is in my past for good; it's way more expensive than having a good write-through cache.

Reply on news.ycombinator.com