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]: [EMAIL PROTECTED]: RE: [Sequoia] DB failover does not seem to be workingDate: 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]: [EMAIL PROTECTED]: Mon, 7 Jul 2008 13:41:56 -0700Subject: Re: [Sequoia] DB failover does not seem to be workingHi 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, RobertOn 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]: [EMAIL PROTECTED]: Mon, 7 Jul 2008 11:54:09 -0700Subject: Re: [Sequoia] DB failover does not seem to be workingHi 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-- Robert Hodges, CTO, Continuent, Inc.Email: [EMAIL PROTECTED]: +1-510-501-3728 Skype: hodgesrm _________________________________________________________________
_______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
