[DRBD-user] StandAlone->Primary/Unknown & StandAlone->Secondary/Unknown

Dave Dykstra dwdha at drdykstra.us
Tue Apr 5 21:10:14 CEST 2005

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


This sounds similar to a case of mine that Philipp Reisner answered.
The archive is at
  http://lists.linbit.com/pipermail/drbd-user/2005-March/002722.html

- Dave

On Thu, Mar 31, 2005 at 06:44:31AM -0800, Shane Walton wrote:
> Hello,
> 
> Consider the following hardware configuration:
> 
> Node A connects to Node B by a switched network and
> Node A connects to Node B by a crossover cable.
> 
> Consider the following software configuration:
> 
> DRBD communicates over the switched network and
> Heartbeat (HA) communicates over both networks.
> 
> Now, following these steps I can repeat the case where
> I have both nodes in a standalone state which requires
> user intervention to reconnect the current PRIMARY
> DRBD node.
> 
> 1.) Node A is DRBD Primary and Node B is DRBD
> Secondary
> 2.) I pull the switched network cable from node A
> 3.) Node A detects the failure and HA moves the
> resources to node B
> 4.) Node B is now StandAlone->Primary/Unknown and node
> A is StandAlone->Secondary/Unknown
> 5.) I reboot node A simulating a NIC replacement and
> reconnect the switched network cable
> 6.) Node B aborts the node A DRBD connection
> complaining that current Primary would be sync TARGET!
> 7.) Node A waits on a degraded connection timeout
> forcing the need to run `drbdadm connect all` on node
> B
> 
> I have read through previous posts and have seen this
> issue mentioned a couple of times with responses
> suggesting to ensure the DRBD net::timeout value is
> lower than the HA deadtime and other suggestions to
> configure DRBD over the crossover cable.
> 
> The timeout change did not make any difference.
> 
> Utilizing the crossover cable adds complications, such
> as if one of the NICs break utilizing the crossover
> cable, assuming the cable doesn't go bad, there is
> data loss deciding which node has a bad NIC.
> 
> The best base would be for the secondary node to have
> the bad NIC as it could sync up later.  If it is the
> primary node, HA would have to move resource to the
> secondary node ignoring the fact that there is data on
> the primary node that did not get copied to the other
> node.
> 
> So my question, is this the expected behavior of DRBD?
> 
> I appreciate your help with this matter and look
> forward to your reply.
> 
> Regards,
> 
> Shane M. Walton



More information about the drbd-user mailing list