Andrew: It&#39;s not that the slave IP doesn&#39;t move back...it&#39;s that the slave IP simply doesn&#39;t run *anywhere*....even when both nodes are up, the slave ip will not run anywhere.  I&#39;m fairly convinced this is a bug....<div>
<br><br><div class="gmail_quote">On Thu, Sep 29, 2011 at 1:21 AM, Andrew Beekhof <span dir="ltr">&lt;<a href="mailto:andrew@beekhof.net">andrew@beekhof.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Sat, Aug 27, 2011 at 9:07 AM, Chris Redekop &lt;<a href="mailto:chris@replicon.com">chris@replicon.com</a>&gt; wrote:<br>
&gt; I&#39;m attempting to set up a master/slave database cluster where the master is<br>
&gt; R/W and the slave is R/O.  The master failure scenario works fine (slave<br>
&gt; becomes master, master vip moves over)....however when the slave resource<br>
&gt; goes down I want the slave vip to move to the master and then move back when<br>
&gt; the slave comes back up...I can&#39;t seem to get this to work properly.  Here&#39;s<br>
&gt; my test config I&#39;m playing with:<br>
&gt; primitive postgresql ocf:custom:pgsql \<br>
&gt;         op monitor interval=&quot;30&quot; timeout=&quot;30&quot; depth=&quot;0&quot;<br>
&gt; primitive primaryip ocf:heartbeat:IPaddr2 \<br>
&gt;         params ip=&quot;10.0.100.102&quot;<br>
&gt; primitive slaveip ocf:heartbeat:IPaddr2 \<br>
&gt;         params ip=&quot;10.0.100.103&quot;<br>
&gt; ms ms_postgresql postgresql \<br>
&gt;         meta clone-max=&quot;2&quot; clone-node-max=&quot;1&quot; master-max=&quot;1&quot;<br>
&gt; master-node-max=&quot;1&quot; notify=&quot;true&quot; target-role=&quot;Started&quot;<br>
&gt; colocation postgres_on_primaryip inf: primaryip ms_postgresql:Master<br>
&gt; colocation slaveip_on_master 101: slaveip ms_postgresql:Master<br>
&gt; colocation slaveip_on_slave 1000: slaveip ms_postgresql:Slave<br>
&gt; property $id=&quot;cib-bootstrap-options&quot; \<br>
&gt;         dc-version=&quot;1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87&quot; \<br>
&gt;         cluster-infrastructure=&quot;openais&quot; \<br>
&gt;         expected-quorum-votes=&quot;2&quot; \<br>
&gt;         stonith-enabled=&quot;false&quot; \<br>
&gt;         no-quorum-policy=&quot;ignore&quot; \<br>
&gt;         last-lrm-refresh=&quot;1314201732&quot;<br>
&gt; rsc_defaults $id=&quot;rsc-options&quot; \<br>
&gt;         resource-stickiness=&quot;100&quot;<br>
&gt; With the configuration like this it looks pretty straight forward but it<br>
&gt; actually results in the slaveip not being run on *either* node.  As far as I<br>
&gt; can figure out it seems when you have a colocation to a specific role it<br>
&gt; implicitly generates a -inf record for the other role.  So the :Master<br>
&gt; generates a -inf for :Slave, and :Slave generates a -inf for :Master, and<br>
&gt; since slaveip has a colocation record for both they get added together<br>
&gt; resulting in a -inf score for both nodes...if I wasn&#39;t so new at this I<br>
&gt; would think that is a bug.  If I key the ip off the node&#39;s up/down status<br>
&gt; (like via &#39;colocation whatever -101: slaveip primaryip&#39;) then it works if I<br>
&gt; standby the slave node but of course it doesn&#39;t work if the resource fails<br>
&gt; while the node stays up.  Can anyone shed some light on how to make this<br>
&gt; work properly?  Thanks!<br>
<br>
</div></div>Are you sure its not just the stickiness value preventing it from<br>
moving back to the slave when it returns?<br>
<div><div></div><div class="h5"><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br>
&gt; <a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
&gt;<br>
&gt; Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>
&gt; Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
&gt; Bugs:<br>
&gt; <a href="http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker" target="_blank">http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker</a><br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br>
<a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker" target="_blank">http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker</a><br>
</div></div></blockquote></div><br></div>