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]
To: [email protected]
Date: Wed, 2 Jul 2008 12:07:30 -0700
Subject: 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, 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?
