It might be easier just to send you the config setup I have, but I would rather
not do that to this list.
I can see how it works if you have one controller with X backends. But in the
case where you have 2 controllers with 2 backends it did not seem to work.
Here is what I did:
- Start both controllers
- Create a dump on C1 and copy it to C2
- enable backends
- Perform some db changes (At this point everything is in sync)
- kill c2 to emulate controller going down
- transfer and restore dump and recovery log
- write to c1
- enable c2 backend
I did not see the change get copied over. I will play more with this as it is
possible that something I did messed things up but your saying that the above
sequence of events should work fine and that the extra change that did not get
copied over in the recovery log restore should be copied over once the backend
is enabled.
> Date: Thu, 10 Jul 2008 01:15:54 +0200> From: [EMAIL PROTECTED]> To:
> [email protected]> Subject: Re: [Sequoia] DB failover does
> not seem to be working> > Hi Adam,> > I am not sure what your configuration
> really is and what exact commands > you are issuing but the writes happening
> during a log transfer or resync > are appended to the recovery log and
> replayed when the backend is > enabled. So when the backend is enabled it
> should be fully synchronized > unless your recovery logs are corrupted (which
> should never happen).> If you find a use case that is not working, please
> don't hesitate to > file a JIRA entry.> > Thanks for your feedback,>
> Emmanuel> > > > Ok, from what I can tell you databases go out of sync.....
> thats not > > good considering the usage our dbs are likely to get...... Is
> there a > > way to solve this that I have not spotted that does not involve
> taking > > both controllers offline inorder to resync them.> >> >> >> >
> ------------------------------------------------------------------------> >
> From: [EMAIL PROTECTED]> > To: [email protected]> > Subject:
> RE: [Sequoia] DB failover does not seem to be working> > Date: Wed, 9 Jul
> 2008 15:52:30 -0400> >> > Well I seem to have most of it working finally
> after some tweaks.> > > > I do have one question I want to confirm however:>
> > > > I have 1 server running and 1 down and I bring up the second server, >
> > transfer a dump over and then start the second backend. What happens > > if
> in between the time I took the dump and the time backend 2 comes > > online a
> write was made to the 1st database. How do we ensure that the > > second one
> is up to date (the two databases in this case are replicas > > of each
> other.).> > > > I am just interested in what is meant to happen. I have
> managed to > > successfully restore the second backend and it gets writes
> made after > > it is running.> >> >> >> >> >
> ------------------------------------------------------------------------> >>
> > From: [EMAIL PROTECTED]> > To: [email protected]> > Date:
> Mon, 7 Jul 2008 13:41:56 -0700> > Subject: Re: [Sequoia] DB failover does not
> seem to be working> >> > Hi Adam,> >> > You need to restore the backup on the
> second controller. The general > > flow is as follows:> >> > 1.) Initialize
> first backend.> > 2.) Dump backend contents. This creates a dump with an
> associated > > checkpoint. You can enable the backend at this time. > > 3.)
> Transfer log and dump to second controller. This gets the > > controllers
> syncrhonized.> > 4.) Load the dump on the second backend.> > 5.) Enable the
> second backend.> >> > At this point your cluster is up and running.> >> >
> Cheers, Robert> >> > On 7/7/08 12:27 PM, "Adam Purkiss" <[EMAIL PROTECTED]>
> wrote:> >> >> > That was the reason it did not start up.> > > > I will see if
> this fixes things> > > > Can I confirm that if I use this then when I restore
> backend DB1> > on controller 1 do I need to restore the same backup on
> controller> > 2 or do I just enable it.> >> >> >> >> >> >> > From: [EMAIL
> PROTECTED]> > _To: [EMAIL PROTECTED]> > _Date: Mon, 7 Jul 2008 11:54:09
> -0700> > Subject: Re: [Sequoia] DB failover does not seem to be working> >> >
> Hi Adam,> >> > Can you check your hedera.properties file and look at the
> JGroups> > config file name? If it is sequencer.xml, you have just hit a> >
> configuration problem that is logged as sequoia-1102, which is> > fixed in
> the codeline. The problem is that the jgroups-all.jar> > file also contains a
> sequencer.xml file with a bad IP address. It> > picks this up before the
> Sequoia version. > >> > To correct the problem, rename config/sequencer.xml
> to> > config/sequoia_sequencer.xml and adjust the name accordingly in> > the
> Hedera properties file referenced by your virtual database. > >> > Thanks,
> Robert> >> >> -- > Emmanuel Cecchet> FTO @ Frog Thinker > Open Source
> Development & Consulting> --> Web: http://www.frogthinker.org> email: [EMAIL
> PROTECTED]> Skype: emmanuel_cecchet> >
> _______________________________________________> Sequoia mailing list>
> [email protected]>
> https://forge.continuent.org/mailman/listinfo/sequoia
_________________________________________________________________
Find hidden words, unscramble celebrity names, or try the ultimate crossword
puzzle with Live Search Games. Play now!
http://g.msn.ca/ca55/212
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
