Thanx. I got it started now. I found another discrepancy that I'm not sure about.. In the demo directory (of 2.10.9), any script that specifies an extra classpath does it with CLASSPATH_XTRA. But the install guide at http://sequoia.continuent.org/doc/2.10/sequoia-install-guide.pdf says it's XTRA_CLASSPATH. Which is correct?
Thanx, -Tony --------------------------- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 [EMAIL PROTECTED] http://www.formatdynamics.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Cecchet Sent: Wednesday, April 09, 2008 8:39 PM To: Sequoia general mailing list Subject: Re: [Sequoia] Controller config problem Hi Tony, The options you are trying to use are not part of the Sequoia 2.9 DTD. The DTD specifies: <!ELEMENT SecuritySettings (Jar?, Accept?, Block?, SSL?)> <!ATTLIST SecuritySettings defaultConnect (true | false) "true" > Note that security settings regarding IP address filtering are going to be dropped in Sequoia 4. You should better use a firewall to efficiently deal with this filtering. Don't hesitate to point obsolete docs and config files so that we can fix them. Thanks for your feedback, Emmanuel > I have a new sequoia install..upon starting the controller I get the > following errors.. My config is below. The order of these elements I got > from the user's guide, and I checked with the > controller-configuration.xml example also, so I'm not sure why it's not > liking them. Any help is appreciated. > > # 17:04:54,668 INFO controller.core.Controller Sequoia controller > (2.10.9) > 17:04:54,855 INFO controller.core.Controller Loading configuration > file: /opt/sequoia-2.10.9-bin/config/controller/controller.xml > 17:04:55,168 ERROR controller.xml.ControllerParser Xml document has not > been validated. > 17:04:55,169 ERROR controller.xml.ControllerParser Element > "SecuritySettings" does not allow "Shutdown" here. > 17:04:55,170 ERROR controller.xml.ControllerParser Element type > "Shutdown" is not declared. > 17:04:55,170 ERROR controller.xml.ControllerParser Element type "Client" > is not declared. > 17:04:55,170 ERROR controller.xml.ControllerParser Attribute "allow" is > not declared for element "Client". > 17:04:55,171 ERROR controller.xml.ControllerParser Attribute > "onlyLocalhost" is not declared for element "Client". > 17:04:55,171 ERROR controller.xml.ControllerParser Element type > "Console" is not declared. > 17:04:55,172 ERROR controller.xml.ControllerParser Attribute "allow" is > not declared for element "Console". > 17:04:55,176 WARN controller.core.Controller Error while analysing xml > configuration file (org.xml.sax.SAXException: Controller Xml > configuration file is not valid.). > org.xml.sax.SAXException: Controller Xml configuration file is not > valid. > at > org.continuent.sequoia.controller.xml.ControllerParser.readXML(Controlle > rParser.java:174) > at > org.continuent.sequoia.controller.xml.ControllerParser.readXML(Controlle > rParser.java:206) > at > org.continuent.sequoia.controller.core.ControllerConfiguration.setUpByXm > l(ControllerConfiguration.java:277) > at > org.continuent.sequoia.controller.core.ControllerConfiguration.setup(Con > trollerConfiguration.java:327) > at > org.continuent.sequoia.controller.core.ControllerConfiguration.getContro > ller(ControllerConfiguration.java:353) > at > org.continuent.sequoia.controller.core.Controller.main(Controller.java:7 > 45) > 17:04:55,179 ERROR controller.core.Controller Could not load config > file: /opt/sequoia-2.10.9-bin/config/controller/controller.xml > (Controller Xml configuration file is not valid.). Loading minimum > configuration. > org.xml.sax.SAXException: Controller Xml configuration file is not > valid. > at > org.continuent.sequoia.controller.xml.ControllerParser.readXML(Controlle > rParser.java:174) > at > org.continuent.sequoia.controller.xml.ControllerParser.readXML(Controlle > rParser.java:206) > at > org.continuent.sequoia.controller.core.ControllerConfiguration.setUpByXm > l(ControllerConfiguration.java:277) > at > org.continuent.sequoia.controller.core.ControllerConfiguration.setup(Con > trollerConfiguration.java:327) > at > org.continuent.sequoia.controller.core.ControllerConfiguration.getContro > ller(ControllerConfiguration.java:353) > at > org.continuent.sequoia.controller.core.Controller.main(Controller.java:7 > 45) > > > <?xml version="1.0" encoding="UTF-8" ?> > > <!DOCTYPE SEQUOIA-CONTROLLER PUBLIC "-//Continuent//DTD > SEQUOIA-CONTROLLER 2.10.9//EN" > "http://sequoia.continuent.org/dtds/sequoia-controller-2.10.9.dtd";> > > <SEQUOIA-CONTROLLER> > <Controller port="25322"> > <Report hideSensitiveData="true" generateOnShutdown="true" > generateOnFatal="true" enableFileLogging="true" /> > <JmxSettings> > <RmiJmxAdaptor/> > </JmxSettings> > <VirtualDatabase configFile="virtualdatabase-FD-console.xml" > virtualDatabaseName="console" autoEnableBackends="true"/> > <SecuritySettings defaultConnect="false"> > <Jar allowAdditionalDriver="true"/> > <Shutdown> > <Client allow="true" onlyLocalhost="true"/> > <Console allow="false"/> > </Shutdown> > <Accept> > <IpAddress value="x.x.x.x"/> > <IpAddress value="x.x.x.x"/> > </Accept> > </SecuritySettings> > </Controller> > </SEQUOIA-CONTROLLER> > > > -Tony > --------------------------- > Manager, IT Operations > Format Dynamics, Inc. > 303-573-1800x27 > [EMAIL PROTECTED] > http://www.formatdynamics.com > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Tuesday, April 08, 2008 2:25 PM > To: Sequoia general mailing list > Subject: Re: [Sequoia] Fault tolerance configuration question > > Emmanuel Cecchet wrote: > >> A RecoveryLog is not recommended but mandatory if you want to recover >> from failures and add new nodes on-the-fly. >> The recovery log can be stored in an embedded database in the recovery >> > > >> log or a standalone database. To prevent the controller from being a >> single point of failure (SPOF) you need a second controller. Each >> controller has its own recovery log, so that the recovery log is not a >> > > >> SPOF either. >> You will have to define a distributed virtual database to synchronize >> activities between controllers and resynchronize recovery logs. More >> details in the Sequoia documentation. >> > > I guess I'm still not seeing how the RecoveryLog avoids being point of > failure. I've looked through the three guides (Administration, > Installation, and User) but fail to see where this is clarified. > > Right now I have two MySQL servers (let's call them M1 and M2) and a > single Sequoia server (let's call it S1) with a virtual database (V1) > comprised of both MySQL servers. > > If I'm understanding correctly for the RecoveryLog to be fault tolerant > it would need to be pointed to yet another virtual database (V2) which > would need to be on at least two servers. Assuming I put it on M1 and > M2, then when either M1 or M2 fail the RecoveryLog would become degraded > > and need to be recovered just like the original virtual database (V1) > would it not? > > If this is covered in the documentation, perhaps someone could point me > to what I've missed? > > >> Next step ... configuring the group communication! ;-) >> > > I wanted to get a grasp of how to avoid what I perceive as a single > point of failure in the RecoveryLog before proceeding with what seems to > > be a more complex configuration. > > -- Emmanuel Cecchet - Research scientist EPFL - LABOS/DSLAB - IN.N 317 Phone: +41-21-693-7558 _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
