Hi Sam, I'll put in my two cents from using Scalr/Amazon over the past month on our production systems. I originally went with the mysqllvm64 role with master/slave replication. I too have large databases, around 50GB or so. My experience was that it would take about 3-5 hours to spool up a new instance. (About 3 hours to bring up a slave and about 5 for a master because the master has to re-upload everything it just downloaded to make sure subsequent slaves have the right data). Which is mostly attributed to the time it takes to download/upload all the pieces of the database from S3. The system ran fine until we ran into a problem where we overloaded the master and the two slaves we had. We were basically down for an entire work day as I was forced to just sit and watch /var/log/messages as piece by piece or our system was restored from S3. This was simply something I could not live with happening again, so here is what I did.
A big part of our problem was the fact that our application is incredibly write heavy. Because of this adding slaves only makes matters worse because they begin to lag so far behind the master that they become of no use. This is not an issue with Scalr/Amazon or any hardware for that matter. It is an issue with the single threaded nature of MySQL replication. I knew we had to start sharding/ partitioning and fast. So I fired up a base64 instance and downloaded the RC for mysql-5.1 which includes partitioning built into MySQL. Also, rather than using /mnt I decided to add another EBS volume to my farm and use that. I have had good experiences with EBS and our clustered file system and was fairly confident that the performance would be fine for our needs. Needless to say, I think I am going to stick with my homegrown solution to MySQL because that's what I need to do for our application. I like the fact that I am in control over scaling the cluster now. Although, I loved the fact before that Scalr took care of everything for me, it just took way too long. I am sure others here can give you their opinions and the solutions they have come up with. Mike On Oct 27, 1:50 pm, sam lee <[EMAIL PROTECTED]> wrote: > Scenario 1: use mysqllvm (or mysqllvm64) role > Scenario 2: run mysql on EBS (by enabling EBS on a mysql role and > setting datadir and log_bin options in my.cnf to point at /mnt/ > storage) > > Which scenario is better overall? We need to store "large" database > and backup frequently. I'm not told how large the database would be. > We are really cautious about losing data. > > Scenario 1 seems to be Ok except that when all mysql instances die, we > might lose data for delta minutes, where delta being rebundle/backup > frequency. > > Scenario 2 can cost us more money since each mysql instance will get a > large EBS. But I assume when they all die, up-to-minute snapshot of > database is on each EBS. Am I correct? > > Would it be better for me to wait until hybrid of EBS/LVM based mysql > roles are available? Is the hybrid being developed? > > Thank you. > Sam. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "scalr-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/scalr-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
