<br><br><div class="gmail_quote">On Thu, Dec 8, 2011 at 10:34 PM, Takatoshi MATSUO <span dir="ltr">&lt;<a href="mailto:matsuo.tak@gmail.com">matsuo.tak@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi Attila<br>
<br>
2011/12/8 Attila Megyeri &lt;<a href="mailto:amegyeri@minerva-soft.com">amegyeri@minerva-soft.com</a>&gt;:<br>
&gt; Hi Takatoshi,<br>
&gt;<br>
<div class="im">&gt; One strange thing I noticed and could probably be improved.<br>
&gt; When there is data inconsistency, I have the following node properties:<br>
&gt;<br>
&gt; * Node psql2:<br>
&gt;    + default_ping_set                  : 100<br>
&gt;    + master-postgresql:1               : -INFINITY<br>
&gt;    + pgsql-data-status                 : DISCONNECT<br>
&gt;    + pgsql-status                      : HS:alone<br>
&gt; * Node psql1:<br>
&gt;    + default_ping_set                  : 100<br>
&gt;    + master-postgresql:0               : 1000<br>
&gt;    + master-postgresql:1               : -INFINITY<br>
&gt;    + pgsql-data-status                 : LATEST<br>
&gt;    + pgsql-master-baseline             : 58:000000004B000020<br>
&gt;    + pgsql-status                      : PRI<br>
&gt;<br>
&gt; This is fine, and understandable - but I can see this only if I do a crm_mon -A.<br>
&gt;<br>
&gt; My problem is, that CRM shows the following:<br>
&gt;<br>
&gt; Master/Slave Set: db-ms-psql [postgresql]<br>
&gt;     Masters: [ psql1 ]<br>
&gt;     Slaves: [ psql2 ]<br>
&gt;<br>
&gt; So if I monitor the system from crm_mon, HAWK or ther tools - I have no indication at all that the slave is running in an inconsistent mode.<br>
&gt;<br>
&gt; I would expect the RA to stop the psql2 node in such cases, because:<br>
&gt; - It is running, but has non-up-to-date data, therefore noone will use it (the slave IP points to the master as well, which is good)<br>
&gt; - In CRM status eveything looks perfect, even though it is NOT perfect and admin intervention is required.<br>
&gt;<br>
&gt;<br>
&gt; Shouldn&#39;t the disconnected PSQL server be stopped instead?<br>
<br>
</div>hmm..<br>
It&#39;s not better to stop PGSQL server.<br>
RA cannot know whether PGSQL is disconnected because of<br>
data-inconsistent or network-down or<br>
starting-up and so on.<br></blockquote><div><br>Why does it matter? If the state is degraded and inconsistent and there is no way to fix it from inside of the RA, RA should probably stop it. Let&#39;s say that there is pgpool running in front of the cluster, keeping an inconsistent node up would lead to the routing SQL queries to it and possibly getting wrong results.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
How about using dummy RA such as vip-slave?<br>
-------------------------------------------<br>
primitive runningSlaveOK ocf:heartbeat:Dummy<br>
.....(snip)<br>
<br>
location rsc_location-dummy runningSlaveOK \<br>
     rule  200: pgsql-status eq &quot;HS:sync&quot;<br>
-------------------------------------------<br></blockquote><div><br>That probably fixes visibility issue. What about notifications on DISCONNECT state? How administrator would know that cluster is inconsistent? May be the better option in this case would be collocating MailTo resource with &quot;HS:alone&quot;?<br>
 <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
Regards,<br>
Takatoshi MATSUO<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://bugs.clusterlabs.org" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Serge Dubrouski.<br>