On 2/1/07, Gérard BUNEL <[EMAIL PROTECTED]> wrote:
I'm maybe completely stupid, maybed really tired. The test I tried was not correct. My objective was to test a backend failure, but as I stopped mysql services, I also put the RecoveryLog in a failed state (yes both are on the same machine, not having sufficient cpu resources).
:)
But, this point out some feature I'm looking at: Alert generation on backend failure, controller failure.
Mmmh, IMHO, it's a real problem that you are able to enable the backend with a failed recovery log. There's something to be done here. A crashed recovery log should be detected to cause a controller failure and you shouldn't be able to enable the failed backend without at least restoring the recovery log. Do you have any warning in your log file to tell you that the recovery log is not accessible? Emmanuel, is it the expected behavior?
How can this be done ? I've seen in the log4j.properties that it could be possible to register an Appender on FATAL level message in order to send alarms, but is there somewhere a list of possible FATAL errors from Sequoia ? is backend or controller failure considered as FATAL ?
I don't think they are. I agree with you that there should be some easy way to monitor Sequoia's activity. It's possible to write JMX services to check that everything is OK in your cluster and call them from Nagios/your monitoring utility via SNMP. It could be a cool contribution to Sequoia :). You can also find an example of a JMX service in doc/examples/jmx/SequoiaNotificationListener.java. It could be cool to develop a more generic service dedicated to monitor a cluster just by giving it the controller configuration file. -- Guillaume Smet Open Wide _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
