And when I brought up the second node in the cluster I get:
 
09:22:49,979 WARN  jgroups.protocols.UDP discarded message from different group 
"iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.230:3325009:22:50,607 WARN  jgroups.protocols.UDP discarded message 
from different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.230:3325209:22:50,640 WARN  jgroups.protocols.UDP discarded message 
from different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.229:3315109:22:50,916 WARN  jgroups.protocols.UDP discarded message 
from different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.230:3325009:22:51,071 WARN  jgroups.protocols.UDP discarded message 
from different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:22:51,122 INFO  controller.virtualdatabase.iasipaiddb 0 
requests were waiting responses from Member(address=/10.99.9.230:33246, 
uid=iasipaiddb)09:22:51,199 WARN  jgroups.protocols.UDP discarded message from 
different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:22:51,212 WARN  sequoia.controller.recoverylog Checkpoint 
Member(address=/10.99.9.230:33250, uid=iasipaiddb) joined group 
iasipaiddb-10.99.9.230:25322-20080708092251106-0400 was stored09:22:51,290 WARN 
 jgroups.protocols.UDP discarded message from different group "iasipaiddb" (our 
group is "iasdsydb"). Sender was 10.99.9.230:3325009:22:51,309 ERROR 
org.jgroups.JChannel exception: java.lang.IllegalStateException: fetching state 
will fail as state transfer is not supported. Add one of the STATE_TRANSFER 
protocols to your protocol configuration09:22:51,332 WARN  
sequoia.controller.recoverylog Checkpoint Member(address=/10.99.9.230:33246, 
uid=iasipaiddb) quit group iasipaiddb-10.99.9.230:25322-20080708092251121-0400 
was stored09:22:51,378 WARN  jgroups.protocols.UDP discarded message from 
different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:22:51,379 WARN  jgroups.protocols.FD_SOCK I was suspected 
by 10.99.9.229:33145; ignoring the SUSPECT message09:22:51,382 WARN  
jgroups.protocols.UDP discarded message from different group "iasipaiddb" (our 
group is "iasdsydb"). Sender was 10.99.9.229:3314509:22:51,386 WARN  
protocols.pbcast.GMS I (10.99.9.230:33250) am not a member of view 
[10.99.9.229:33145|6] [10.99.9.229:33145], shunning myself and leaving the 
group (prev_members are [10.99.9.229:33145 10.99.9.230:33250 ], current view is 
[10.99.9.229:33145|5] [10.99.9.229:33145, 10.99.9.230:33250])09:22:51,392 WARN  
jgroups.protocols.UDP discarded message from different group "iasipaiddb" (our 
group is "iasdsydb"). Sender was 10.99.9.230:3325009:22:51,440 INFO  
controller.virtualdatabase.iasipaiddb 0 requests were waiting responses from 
Member(address=/10.99.9.229:33145, uid=iasipaiddb)09:22:51,451 WARN  
sequoia.controller.recoverylog Checkpoint Member(address=/10.99.9.229:33145, 
uid=iasipaiddb) quit group iasipaiddb-10.99.9.230:25322-20080708092251438-0400 
was stored09:22:51,580 WARN  jgroups.protocols.UDP discarded message from 
different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.229:3315109:22:51,590 WARN  jgroups.protocols.UDP discarded message 
from different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.230:3325209:22:52,071 WARN  jgroups.protocols.UDP discarded message 
from different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.229:3315109:22:52,121 INFO  controller.virtualdatabase.iasdsydb 0 
requests were waiting responses from Member(address=/10.99.9.230:33248, 
uid=iasdsydb)09:22:52,129 WARN  sequoia.controller.recoverylog Checkpoint 
Member(address=/10.99.9.229:33151, uid=iasdsydb) joined group 
iasdsydb-10.99.9.230:25322-20080708092252116-0400 was stored09:22:52,138 WARN  
sequoia.controller.recoverylog Checkpoint Member(address=/10.99.9.230:33252, 
uid=iasdsydb) joined group iasdsydb-10.99.9.230:25322-20080708092252119-0400 
was stored09:22:52,146 ERROR continuent.hedera.channel Unhandled JGroups 
message type (class org.jgroups.ExitEvent): ExitEvent.09:22:52,186 WARN  
jgroups.protocols.UDP discarded message from different group "iasipaiddb" (our 
group is "iasdsydb"). Sender was 10.99.9.229:3314509:22:52,192 ERROR 
org.jgroups.JChannel exception: java.lang.IllegalStateException: fetching state 
will fail as state transfer is not supported. Add one of the STATE_TRANSFER 
protocols to your protocol configuration09:22:52,273 INFO  
controller.virtualdatabase.iasdsydb 0 requests were waiting responses from 
Member(address=/10.99.9.229:33151, uid=iasdsydb)09:22:52,291 WARN  
protocols.pbcast.NAKACK [10.99.9.230:33250] discarded message as start() has 
not been called, message: [dst: <null>, src: <null> (1 headers), size = 0 
bytes]09:22:52,385 WARN  jgroups.protocols.FD_SOCK I was suspected by 
10.99.9.229:33151; ignoring the SUSPECT message09:22:52,408 WARN  
protocols.pbcast.GMS I (10.99.9.230:33252) am not a member of view 
[10.99.9.229:33151|20] [10.99.9.229:33151], shunning myself and leaving the 
group (prev_members are [10.99.9.229:33151 10.99.9.230:33252 ], current view is 
[10.99.9.229:33151|19] [10.99.9.229:33151, 10.99.9.230:33252])09:22:52,446 WARN 
 protocols.pbcast.NAKACK [10.99.9.230:33252] discarded message as start() has 
not been called, message: [dst: <null>, src: <null> (1 headers), size = 0 
bytes]09:22:52,455 WARN  sequoia.controller.recoverylog Checkpoint 
Member(address=/10.99.9.230:33248, uid=iasdsydb) quit group 
iasdsydb-10.99.9.230:25322-20080708092252120-0400 was stored09:22:52,480 WARN  
sequoia.controller.recoverylog Checkpoint Member(address=/10.99.9.229:33151, 
uid=iasdsydb) quit group iasdsydb-10.99.9.230:25322-20080708092252268-0400 was 
stored09:22:52,482 ERROR continuent.hedera.channel Unhandled JGroups message 
type (class org.jgroups.ExitEvent): ExitEvent.And there are some errors which 
worry me.



From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: RE: [Sequoia] DB failover does not 
seem to be workingDate: Tue, 8 Jul 2008 09:17:15 -0400


Is the following logs normal for running in a cluster: 09:14:24,006 INFO  
controller.RequestManager.iasipaiddb Resuming activity for 
iasipaiddb09:14:24,048 WARN  jgroups.protocols.UDP discarded message from 
different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:14:24,090 WARN  jgroups.protocols.UDP discarded message 
from different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:14:24,121 INFO  controller.RequestManager.iasipaiddb All 
activity is now resumed for iasipaiddb09:14:24,122 INFO  
controller.recoverylog.RecoverThread Database backend DB1 is now 
enabled09:14:24,495 WARN  jgroups.protocols.UDP discarded message from 
different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:14:27,754 WARN  jgroups.protocols.UDP discarded message 
from different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.229:3314309:14:28,757 WARN  jgroups.protocols.UDP discarded message 
from different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.229:3314309:14:32,464 WARN  jgroups.protocols.UDP discarded message 
from different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:14:33,466 WARN  jgroups.protocols.UDP discarded message 
from different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:14:35,115 WARN  jgroups.protocols.UDP discarded message 
from different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.229:3314309:14:36,118 WARN  jgroups.protocols.UDP discarded message 
from different group "iasdsydb" (our group is "iasipaiddb"). Sender was 
10.99.9.229:3314309:14:41,887 WARN  jgroups.protocols.UDP discarded message 
from different group "DefaultPartition" (our group is "iasipaiddb"). Sender was 
127.0.0.1:3277109:14:41,889 WARN  jgroups.protocols.UDP discarded message from 
different group "DefaultPartition" (our group is "iasdsydb"). Sender was 
127.0.0.1:3277109:14:42,013 WARN  jgroups.protocols.UDP discarded message from 
different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:14:42,895 WARN  jgroups.protocols.UDP discarded message 
from different group "DefaultPartition" (our group is "iasipaiddb"). Sender was 
127.0.0.1:3277109:14:42,896 WARN  jgroups.protocols.UDP discarded message from 
different group "DefaultPartition" (our group is "iasdsydb"). Sender was 
127.0.0.1:3277109:14:43,018 WARN  jgroups.protocols.UDP discarded message from 
different group "iasipaiddb" (our group is "iasdsydb"). Sender was 
10.99.9.229:3314509:14:44,138 WARN  jgroups.protocols.UDP discarded message 
from different group "DefaultPartition" (our group is "iasipaiddb"). Sender was 
127.0.0.1:3277109:14:44,139 WARN  jgroups.protocols.UDP discarded message from 
different group "DefaultPartition" (our group is "iasdsydb"). Sender was 
127.0.0.1:3277109:14:44,257 WARN  jgroups.protocols.UDP discarded message from 
different group "DefaultPartition" (our group is "iasdsydb"). Sender was 
127.0.0.1:3277109:14:44,263 WARN  jgroups.protocols.UDP discarded message from 
different group "DefaultPartition" (our group is "iasipaiddb"). Sender was 
127.0.0.1:32771 It is really annoying as its filling my logs and potentially 
hiding something I care about. Or does the above mean something is wrong. As 
the moment I just have the one controller 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

Reply via email to