Hi Holger, On Mon, Feb 07, 2011 at 11:38:10AM +0100, Holger Teutsch wrote: > On Mon, 2011-02-07 at 08:42 +0100, Florian Haas wrote: > > Hello Holger, > > > > that would be excellent functionality to have, thanks very much for the > > contribution! Is there any chance this could be rolled into the existing > > db2 agent? You could use the ocf_is_ms() function to detect whether the > > resource is configured as a master/slave set or as a primitive, and > > based on that determine whether to use HADR or not. Does that sound > > feasible at all? > > Hi Florian, > I thought about this as well. Unfortunately I don't consider this > feasible. > > Some background: > DB2 has an instance and within the instances databases that can be > activated or not. That means databases can be activated (=started) > individually but they more or less fail or are (forced) shut down > together. Obviously best practice asks for an instance per db in > particular as an instance is pretty lightweight from a resource > perspective. > > The existing db2 agent makes an *instance* highly available. As a result > once a *single* database fails the *whole* instance is bounced. > The multipartition support I brought in recently is not available at > all for HADR. > > For HADR the situation is different. Ok, the instance must run but > tracking and moving an individual DB through all required state > transitions is the task. Therefore there it has a required parameter > "db" designating the DB at issue and individual commands for stopping > and start HADR are quite different from the standard case.
That looks like an entirely different beast, if I got it right this RA manages databases rather than instances. If so, then it does deserve it's own RA. > As conclusion: > 1) > Rolling HADR into the existing agent seems impossible to me or > at least will end in a pollution of if and case statement and > over complex logic. > > 2) > Adding support for a standard database in the one instance / one > db model is feasible. As explained above this will not be > 'binary' compatible to the existing agent. > > 3) > The db2 agent seems to have a long and complex heritage as agent > for different HA solutions or as standalone script so a major > refurbishment is on my To-Do list anyhow. > Moving common code into a helper script as 'library' to be > shared by both agents might be an idea. Actually, we have a changeset ready (just not in the repository yet) which allows splitting agents into several files or creating such a common library. > Opinions ? Know next to nothing about db2, so I don't really have an informed one :) Cheers, Dejan > Regards > Holger > > > > > Cheers, > > Florian > > > _______________________________________________________ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
