[DRBD-user] expected behaviour after primary crash and reconnect.

Bernd Schubert bernd-schubert at web.de
Wed Mar 23 20:02:48 CET 2005

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

Hello Peter,

> Finally a chance to try drbd 0.7.10 with kernel 2.6.11 :-)  and already
> have a question:

Philipp recently wrote something about performance problems with 2.6.11, so we 
are still at 2.6.10-as. Maybe there are other problems as well?

> what is the expected behaviour if primary goes down, secondary takes
> over (via "drbdadm primary <resource>") and old primary comes up again?

AFAIK, both nodes should automatically connect and the modified data will be 
synced from the primary to the secondary. That is also working here fine.

> I observed that the new primary goes into StandAlone Primary/Unknown
> state and stays there.  On boot of the old primary the connection
> is not made automatically, instead I have to do
> "drbdadm connect <resource>" on the new primary to initiate the
> partial sync.  Why is it not possible to initiate the connection
> on the old primary?

Hmm, I guess you are using the debian start scripts? In the start part there 
should be 

$DRBDADM wait_con_int # User interruptible version of wait_connect all

This should make the old primary to wait going on with the boot process until 
a connection is established. There should be something on the console.

> I would expect that on boot of the old primary the connection
> is done automatically and initiated by the old primary.
> How can I accomplish this?  Would it be enough to just
> do "drbdadm connect <resource>" right after "drbdadm primary <resource>"
> even if the peer is not available?

This should't be neccessary at all. What does your logfiles say? Does it work 
if you manually do a /etc/init.d/drdb restart (in very rare case we also have 
to do this)? 
Rebooting shouldn't be neccessary to basically test the situation. Just 
stopping drbd on the master node, making the device primary on the failover 
and starting drbd on the master node should be sufficient.


Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert at pci.uni-heidelberg.de

More information about the drbd-user mailing list