<br><br><div class="gmail_quote">On Tue, Mar 9, 2010 at 12:20 AM, Andrew Beekhof <span dir="ltr"><<a href="mailto:andrew@beekhof.net">andrew@beekhof.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Mon, Mar 8, 2010 at 9:37 PM, hj lee <<a href="mailto:kerdosa@gmail.com">kerdosa@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> In the typical multi-state resource agent, it changes master score on demote<br>
> or promote. Each change in master score triggers PE calculation. Suppose the<br>
> following scenario.<br>
> 1. Pacemaker initiates demote/promote<br>
> 2. demote is issued and lower the master score on the demoted node.<br>
> 3. promote is issued and increases the master score on the promoted node.<br>
><br>
> The PE calculation can be kicked off between 2 and 3, then the pacemaker<br>
> will see two slaves in the moment. Depending on the master score it sees at<br>
> the moment, the pacemaker may promote the old master.<br>
<br>
</div>Is this a theoretical problem or one you've seen?<br>
Because we'd only demote the old master if we wanted to promote a different one.<br>
And demoting the old master would make it even less likely to be<br>
re-promoted than before.<br>
<br>
So I don't really see the issue.<br>
<div class="im"><br></div></blockquote></div>I saw it in our servers. The master node is demoted and promoted again. This is a big problem in our cluster. Once the pacemaker scheduled demote/promote, it should complete the scheduled demote/promote. If the pacemaker can not process this demote/promote in multistate clone, then there will be resources having a problem.<br>
<br>Thanks<br>hj <br>