<div dir="ltr"><div dir="ltr">Andrei,<div>You are right, thank you. I have an earlier thread on which I posted a pacemaker.log for this issue, and didn't think to point to it here.</div><div>The link is <a href="http://project.ibss.net/samples/deidPacemakerLog.2021-01-25.txt">http://project.ibss.net/samples/deidPacemakerLog.2021-01-25.txt</a> .</div><div>So, node01 is in maintenance mode, and constraints prevent any resources from running on it (other than drbd in Secondary). I would not want node01 to ston[node02]ith after a communications failure, especially not if all resources are running fine on node02.</div><div>Also I did not think to wonder if node01 could become DC even though in maintenance mode.</div><div>The logs seem to me to match this contention. The cib ops happen right in the middle of the DC negotiations.</div><div>Is there a way to tell node01 that it cannot be DC? Like a constraint?</div><div>Thanks again.</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 31, 2021 at 1:55 AM Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com">arvidjaar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">29.01.2021 20:37, Stuart Massey пишет:<br>
> Can someone help me with this?<br>
> Background:<br>
> <br>
> "node01" is failing, and has been placed in "maintenance" mode. It<br>
> occasionally loses connectivity.<br>
> <br>
> "node02" is able to run our resources<br>
> <br>
> Consider the following messages from pacemaker.log on "node02", just after<br>
> "node01" has rejoined the cluster (per "node02"):<br>
> <br>
> Jan 28 14:48:03 [21933] <a href="http://node02.example.com" rel="noreferrer" target="_blank">node02.example.com</a>        cib:     info:<br>
> cib_perform_op:       --<br>
> /cib/status/node_state[@id='2']/transient_attributes[@id='2']<br>
> Jan 28 14:48:03 [21933] <a href="http://node02.example.com" rel="noreferrer" target="_blank">node02.example.com</a>        cib:     info:<br>
> cib_perform_op:       +  /cib:  @num_updates=309<br>
> Jan 28 14:48:03 [21933] <a href="http://node02.example.com" rel="noreferrer" target="_blank">node02.example.com</a>        cib:     info:<br>
> cib_process_request:  Completed cib_delete operation for section<br>
> //node_state[@uname='<a href="http://node02.example.com" rel="noreferrer" target="_blank">node02.example.com</a>']/transient_attributes: OK (rc=0,<br>
> origin=<a href="http://node01.example.com/crmd/3784" rel="noreferrer" target="_blank">node01.example.com/crmd/3784</a>, version=0.94.309)<br>
> Jan 28 14:48:04 [21938] <a href="http://node02.example.com" rel="noreferrer" target="_blank">node02.example.com</a>       crmd:     info:<br>
> abort_transition_graph:       Transition aborted by deletion of<br>
> transient_attributes[@id='2']: Transient attribute change | cib=0.94.309<br>
> source=abort_unless_down:357<br>
> path=/cib/status/node_state[@id='2']/transient_attributes[@id='2']<br>
> complete=true<br>
> Jan 28 14:48:05 [21937] <a href="http://node02.example.com" rel="noreferrer" target="_blank">node02.example.com</a>    pengine:     info:<br>
> master_color: ms_drbd_ourApp: Promoted 0 instances of a possible 1 to master<br>
> <br>
> The implication, it seems to me, is that "node01" has asked "node02" to<br>
> delete the transient-attributes for "node02". The transient-attributes<br>
> should normally be:<br>
>       <transient_attributes id="2"><br>
>         <instance_attributes id="status-2"><br>
>           <nvpair id="status-2-master-drbd_ourApp"<br>
> name="master-drbd_ourApp" value="10000"/><br>
>           <nvpair id="status-2-pingd" name="pingd" value="100"/><br>
>         </instance_attributes><br>
>       </transient_attributes><br>
> <br>
> These attributes are necessary for "node02" to be Master/Primary, correct?<br>
> <br>
> Why might this be happening and how do we prevent it?<br>
> <br>
<br>
You do not provide enough information to answer. At the very least you<br>
need to show full logs from both nodes around time it happens (starting<br>
with both nodes losing connectivity).<br>
<br>
But as a wild guess - you do not use stonith, node01 becomes DC and<br>
clears other node state.<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</blockquote></div>