<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>Hello,<br><br>Under the Clusters from Scratch documentation, allow-two-primaries is set in the DRBD configuration for an active/passive cluster:<br>http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/html-single/Clusters_from_Scratch/index.html#_write_the_drbd_config<br><br>"TODO: Explain the reason for the allow-two-primaries option"<br><br>Is the reason for allow-two-primaries in this active/passive cluster (using ext4, a non-cluster filesystem) to allow for failover in the type of situation I have described (where the old primary/master is suddenly offline like with a power supply failure)? Are split-brains prevented because Pacemaker ensures that only one node is promoted to Primary at any time?<br><br>Is it possible to recover from such a failure without allow-two-primaries?<br><br>Thanks,<br><br>Andrew<br><br><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Andrew Martin" &lt;amartin@xes-inc.com&gt;<br><b>To: </b>"The Pacemaker cluster resource manager" &lt;pacemaker@oss.clusterlabs.org&gt;<br><b>Sent: </b>Friday, October 19, 2012 10:45:04 AM<br><b>Subject: </b>[Pacemaker] Behavior of Corosync+Pacemaker with DRBD primary power&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;loss<br><br><style>p { margin: 0; }</style><div style="font-family: Times New Roman; font-size: 12pt; color: #000000">Hello,<br><br>I have a 3 node Pacemaker + Corosync cluster with 2 "real" nodes, node0 and node1, running a DRBD resource (single-primary) and the 3rd node in standby acting as a quorum node. If node0 were running the DRBD resource, and thus is DRBD primary, and its power supply fails, will the DRBD resource be promoted to primary on node1?<br><br>If I simply cut the DRBD replication link, node1 reports the following state:<br>Role:<br>Secondary/Unknown<br><br>Disk State:<br>UpToDate/DUnknown<br><br>Connection State:<br>WFConnection<br><br><br>I cannot manually promote the DRBD resource because the peer is not outdated:<br>0: State change failed: (-7) Refusing to be Primary while peer is not outdated<br>Command 'drbdsetup 0 primary' terminated with exit code 11<br><br>I have configured the CIB-based crm-fence-peer.sh utility in my drbd.conf<br>fence-peer "/usr/lib/drbd/crm-fence-peer.sh";<br>but I do not believe it would be applicable in this scenario.<br><br>If node0 goes offline like this and doesn't come back (e.g. after a STONITH), does Pacemaker have a way to tell node1 that its peer is outdated and to proceed with promoting the resource to primary?<br><br>Thanks,<br><br>Andrew<br></div><br>_______________________________________________<br>Pacemaker mailing list: Pacemaker@oss.clusterlabs.org<br>http://oss.clusterlabs.org/mailman/listinfo/pacemaker<br><br>Project Home: http://www.clusterlabs.org<br>Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>Bugs: http://bugs.clusterlabs.org<br></div><br></div></body></html>