you are on the right way since the snapshot was successfully fetched. It
takes some time afterwards to extract and check tables...but it seems right.
I guess bundling is an independent process and it depends on the frequency
you set for it...if you set it to 1 hour then an hour after it started it
will issue a trap.

On Fri, Jan 30, 2009 at 4:29 PM, Mike <[email protected]> wrote:

>
> I seem to be having a meaningful discussion with myself.  :)  As I'm
> waiting (still) for the new instance to come up, I'm wondering why,
> after the snapshot is downloaded and extracted scalr decides it needs
> to do a new bundle:
>
> 30-01-2009 08:18:28     INFO    otalonet        i-4a2fa323/mysql-init.sh
> Bundling MySQL data.
> 30-01-2009 08:16:04     INFO    otalonet        i-4a2fa323/mysql-init.sh
> Snapshot successfully extracted.
> 30-01-2009 08:13:49     INFO    otalonet        i-4a2fa323/mysql-init.sh
> Extracting MySQL data snapshot.
> 30-01-2009 08:13:48     INFO    otalonet        i-4a2fa323/mysql-init.sh
> Successfully fetched snapshot from s3://farm-864-736584309121/farm-
> mysql/mysql-snapshot.tar.
> 30-01-2009 08:11:02     INFO    otalonet        i-4a2fa323/mysql-init.sh
>      Trying
> to fetch previous MySQL snapshot from s3://farm-864-736584309121/farm-
> mysql/mysql-snapshot.tar (3581143040 bytes).
>
> Am I miss interpreting this?  From the log message, I get the
> impression that it is doing the bundle process where it takes a
> snapshot of the DB. Is that not the case?  What I do know is that the
> DB server is still not up, as I wait on this bundling step.  And I've
> changed the host up timeout to 1200 now, as time stretches on...
>
> -Mike
>
> On Jan 30, 9:16 am, Mike <[email protected]> wrote:
> > Ok.  Trying it with the hostUp timeout changed to 900 instead of 300.
> > Will chunking the DB snapshot (which I've heard talked about in
> > various discussions for the next release) allow scalr to download
> > multiple chunks in parallel and trim the time it takes to bring a new
> > DB instance up?  Because the snapshot is 3.5G, which is big, but not
> > all that big for a production DB.
> >
> > On Jan 30, 9:03 am, Mike <[email protected]> wrote:
> >
> > > Well, I've been watching all of these discussions about DB's going
> > > down and then not coming back up, but feeling good that it hasn't
> > > happened to me.  Now my site is down.  And the DB seems to be
> > > struggling to come back up.  It is a production site, that was
> > > featured on TechCrunch a couple weeks back (http://www.otalo.com).
> > > The farm ID is.
> >
> > > The MySQL machines keep relaunching and trying to come up.  The log
> > > messages I see get to this point:
> >
> > > 30-01-2009 07:57:36     INFO    otalonet
>  i-912da1f8/mysql-init.sh
> > > Trying to fetch previous MySQL snapshot from s3://
> > > farm-864-736584309121/farm-mysql/mysql-snapshot.tar (3581143040
> > > bytes).
> > > 30-01-2009 07:57:27     INFO    otalonet
>  i-912da1f8/mysql-init.sh
> > > Stopping MySQL server.
> > > 30-01-2009 07:57:18     INFO    otalonet
>  i-912da1f8/trap-inithost.sh
> > > Received INIT trap from UDP: [174.132.108.66]:65015 (AWS account ID:
> > > 736584309121). Finishing host start-up.
> > > 30-01-2009 07:57:13     INFO    otalonet
>  i-912da1f8/instance-init.sh     Host
> > > 10.250.159.32/mysql initialized. Awaiting authentication data.
> >
> > > And then the instance terminates and a new one starts.  Please help as
> > > this is a production system with hundreds of users trying to access
> > > the site.
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to