ok thanks.
I have a question following on from this then about the Recovery Log. This
might me my misunderstanding of Sequoia so please bear with me. I am trying to
read all the documentation but my head is spinning, lol.
You Have two controllers (C) and two database servers (DS). The documentation
states that the recovery log for controller one cannot be the same as for
controller two so although they are updating the same database there are two
recovery logs per db. If the recovery log for C1 is on DS1 and DS1 goes down I
assume that due to replication (Raidb-1) DS2 has a duplicate recovery log and
so can pick up the slack or do you loose your recovery log? Or should I not
care that much about the RL and just have a local RL based on some other DB and
save the database machines only for the application databases.
If the later is the case and they refer to the same DBs with different RL then
when I reinit the DBs I need to copy over the recovery log but not the db dump
to controller 2?
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Wed, 2 Jul 2008 12:07:30
-0700Subject: Re: [Sequoia] stored procedure creation/DB reseeding
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,
RobertOn 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]: [EMAIL PROTECTED]: Wed, 2 Jul 2008 09:01:54
-0700Subject: Re: [Sequoia] stored procedure creation/DB reseedingHi 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, RobertOn 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]: [EMAIL PROTECTED]: Wed, 2 Jul 2008 08:43:56
-0700Subject: Re: [Sequoia] stored procedure creation/DB reseedingHi 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, RobertOn 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> -- Robert Hodges, CTO,
Continuent, Inc.Email: [EMAIL PROTECTED]: +1-510-501-3728 Skype: hodgesrm
_________________________________________________________________
Have fun while connecting on Messenger! Click here to learn more.
http://entertainment.sympatico.msn.ca/WindowsLiveMessenger
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
