Hi Dejan, On Thu, 2011-02-24 at 11:08 +0100, Dejan Muhamedagic wrote: > Hi Holger, > > On Wed, Feb 23, 2011 at 06:03:21PM +0100, Holger Teutsch wrote: > > Hi Dejan, > > > > On Wed, 2011-02-23 at 11:54 +0100, Dejan Muhamedagic wrote: > > > Hi Holger, > > > > > > On Tue, Feb 22, 2011 at 06:25:37PM +0100, Holger Teutsch wrote: > > > > Hi, > > > > I resubmit the db2 agent for inclusion into the project. Besides fixing ....
> > > > @@ -417,8 +445,12 @@ > > > > ocf_log err "Possible split brain ! Manual > > > > intervention required." > > > > ocf_log err "If this DB is outdated use \"db2 start > > > > hadr on db $db as standby\"" > > > > ocf_log err "If this DB is the surviving primary use > > > > \"db2 start hadr on db $db as primary by force\"" > > > > - # should we return OCF_ERR_INSTALLED instead ? > > > > - # might be a timing problem > > > > + > > > > + # might be a timing problem because "First active log" > > > > is delayed > > > > + # sleep long so we won't end up in a high speed retry > > > > loop > > > > + # lrmd will kill us eventually on timeout > > > > + # on the next start attempt we might succeed when FAL > > > > was advanced > > > > + sleep 36000 > > > > > > Perhaps you should still remove this sleep. If there's nothing > > > that can be done without administrator intervention, then better > > > exit soon and let the cluster try to recover whichever way it can > > > (depending also on how it is configured). > > > > > > > Yes, but we can end up in a "high speed" restart loop. Instead of > > putting in some random sleep I felt that relying on the administrator's > > timeout choice is better. > > Well, the RA should always tell the truth and in this case it > gives an impression that there was a timeout even though there > wasn't one. What is it actually that should or shouldn't happen > at this point? Does it want to say: "I cannot be started anymore > on this node"? Is that just a temporary condition? BTW, even if > it gets into a restart loop, that cannot make things any worse, > right? I can't say really, but somehow doing an artificial > timeout doesn't look right. The scenario is: "I am a lonesome Primary and could not connect to my Standby during startup within HADR_TIMEOUT seconds" So multiple causes, multiple possible resolutions... -> no sleep, return the truth: generic error Regards Holger ------------------ reference ----------------------- --- a/db2 Wed Feb 23 18:24:59 2011 +0100 +++ b/db2 Thu Feb 24 16:15:55 2011 +0100 @@ -446,11 +446,11 @@ ocf_log err "If this DB is outdated use \"db2 start hadr on db $db as standby\"" ocf_log err "If this DB is the surviving primary use \"db2 start hadr on db $db as primary by force\"" + # might be the Standby is not yet there # might be a timing problem because "First active log" is delayed - # sleep long so we won't end up in a high speed retry loop - # lrmd will kill us eventually on timeout - # on the next start attempt we might succeed when FAL was advanced - sleep 36000 + # on the next start attempt we might succeed when FAL was advanced + # might be manual intervention is required + # ... so let pacemaker give it another try and we will succeed then return $OCF_ERR_GENERIC ;;
db2
Description: application/shellscript
_______________________________________________________ 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/