>>You can, of course, host the meta-data controler as a clustered >>resource; for example, a standard fail-over MySQL setup on top of drbd. >>Problem solved.
Yes, that is a working solution. Here is why I decided I did not like that method. I have two more pieces of software to manage, MySQL and DBRD. The cluster starts as two nodes and then grows to 8. DRBD is on Node1 and Node2. The mysql and DRBD can not automatically move like data in the CIB can. Even if you argue that it is easy to move, it is still a manual process. >> One day, someone will want billing, someone will additional flags, >> account meta-information etc, not all of which can or should be stored >> in the CIB (among other things, it is not encrypted). Yes, the author of the changes would have to do their own encryption outside of LINUX HA. I can assume that the CIB file is safe and the transmission is on trusted networks, so no security issues. More or less the same issues as DRBD replication or MySQL replication. Of course if someone like me were to go out and change the DTD all bets would be off in terms of support. I was planning to handle the change like this. I figured this would have the least chance of impact. <!ELEMENT cib (configuration, status,mystuff?)> <!ELEMENT mystuff ANY> Since the cib.xml seems to lack xml namspace support I also planned to prefix any element under mystuff with mystuffmything. That should have minimal impact on linux-ha. > At the very least, I'd suggest that you go and enhance CIB to support > several database roots - stored in different files too - so that your > proprietary data does not end up in the general CIB used by the PE and > other tools. This is a good idea. Ill look into this. I can get it done faster by hacking my way into the general CIB. In the long run I agree that this would be a better way to go. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
