Hi Adam,

That's correct-you would need to shut down the VDB on both machines.  We 
actually have a fix in the 2.10 line that does a global shutdown of the VDB 
that we are testing right now.  It's logged as Sequoia-1108 ( 
https://forge.continuent.org/jira/browse/SEQUOIA-1108).  Sorry that the 
description is a bit parsimonious.  However, it should work shortly.

Cheers, Robert

On 7/2/08 11:57 AM, "Adam Purkiss" <[EMAIL PROTECTED]> wrote:

For point 5 assuming that if two controllers looking at the same set of 
databases I assume you do not need to do anything with regards copying to 
controllers but would restore the dump and recovery log dump to each machine, 
but when you shutdown your VDB you do need to stop it on both controllers 
before continuing.

The configuration we are looking for is X databases to provide failover at that 
level and also X controllers to provide controller failover. At least that was 
the case last time I checked.




________________________________

From: [EMAIL PROTECTED]
To: [email protected]
Date: Wed, 2 Jul 2008 09:01:54 -0700
Subject: Re: [Sequoia] stored procedure creation/DB reseeding

Hi Adam,

You would need to something like the following:

1.) Shut down the VDB that you are going to re-initialize.
2.) Load data into one of the backends for that VDB.
3.) Load the VDB and force initialization to that backend.  This resets the 
recovery log.
4.) Backup the backend once initialized.
5.) Transfer the recovery log and dump (if necessary) to other controllers in 
the cluster.
6.) Restore the dump on each backend.
7. ) Enable all backends.

You can actually enable the first backend used for initialization as soon as 
the dump is completed.

This is a lot of steps as you can guess.  I would recommend scripting it in 
Perl if you can.

Cheers, Robert


On 7/2/08 8:56 AM, "Adam Purkiss" <[EMAIL PROTECTED]> wrote:


It is MySQL.

True, but I thought if you reint a db then sequoia gets unhappy and then you 
have the admin nightmare of orting out the mess. Or is there a nice automatic 
way of dealing with this? When I tried to reint my single db test setup sequoia 
certainly got very unhappy and I had to reinit and all sorts.

Is there somewhere to look for what you describe or could you explain the steps 
that would be followed to do the below.

For example : shutdown databases... etc etc etc.

thanks








________________________________

From: [EMAIL PROTECTED]
To: [email protected]
Date: Wed, 2 Jul 2008 08:43:56 -0700
Subject: Re: [Sequoia] stored procedure creation/DB reseeding

Hi Adam,

Just a question-wouldn't it be easier to deploy directly to one database and 
then re-init the cluster from that?  You don't mention your database type but 
assuming it's MySQL dump format this would be the easiest way.  Sequoia does 
not currently support that syntax fully.

Cheers, Robert


On 7/2/08 8:01 AM, "Adam Purkiss" <[EMAIL PROTECTED]> wrote:


The result of this may be a need to change how we deploy/redeploy databases but 
I will ask anyway


I have managed to get sequoia to work with our existing mysql databases 
including it calls made to stored procedures which is great. I have yet to try 
it on something other then my local box with more then one db but that is a 
challenge for another day. Right now I am attempting to rework our seed scripts 
to work through sequoia so when we redeploy and want to wipe the database we 
can. I have taken out things like IF Exists calls (though it would be nice if 
sequoia supported that) so I can recreate the tables fine. However when I start 
on the stored procedures which change delimiter to $$ I get the following error:

org.continuent.sequoia.common.exceptions.driver.DriverSQLException: Message of 
cause: Failed to execute request CREATE PROCEDURE XXX(IN... because of 
(org.continuent.sequoia.controller.requests.StoredProcedure cannot be cast to 
org.continuent.sequoia.controller.requests.AbstractWriteRequest)

Does this mean that sequoia cannot be used to reseed, or is there something 
different I need to do with the seed sql?

I know I could just ignore the recreation of SPs and views but my concern is 
that this is fine until one day we decide to change one.


I am looking for both short and long term solutions. So for example is their an 
automated way I could get sequoia to rollback to the inital db state? If I have 
changes to stored procedures is there a way without going through sequoia to 
make the change that will not make sequoia unstable?


Thoughts? Options?






________________________________
Send a smile, make someone laugh, have some fun! Start now! 
<http://www.freemessengeremoticons.ca/?icid=EMENCA122><http://www.freemessengeremoticons.ca/?icid=EMENCA122>




--
Robert Hodges, CTO, Continuent, Inc.
Email:  [EMAIL PROTECTED]
Mobile:  +1-510-501-3728  Skype:  hodgesrm
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to