[DRBD-user] Replication for disaster recovery

Velko veljko3 at gmail.com
Sun Apr 27 20:00:05 CEST 2014

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

On 2014-Apr-26 13:05, Lars Ellenberg wrote:
> We cannot easily "demote" ourselves.
> We can however freeze IO on connection loss,
> which is exactly what happens if you configure
>   fencing resource-and-stonith;
> It will then freeze IO,
> call the "fence-peer" handler (a script you can define in drbd.conf)
> and unfreeze IO only once that handler returned an expected exit code,
> the connection is re-established,
> or the admin explicitly resumes IO.
> In theory you could try to 
>    force disconnect,
>    then force detach,
>    then resume
> And all file systems/applications on top of it will get IO errors,
> and may then panic ;-)
> Maybe easier to just have it freeze,
> and start a timer... if it is still frozen
> after $timeout, hard-reset ;-)
> You could talk with LINBIT,
> we can make it work the way you need it.
> [if that is technically possible;
>  which is why I not said "the way you want it" ...
>  experience shows that people "want" protocol P,
>  the predictive mode... ;-)]

Hi Lars and thanks for your answer.

My question was XY problem, obviously. I didn't read through DRBD
documentation enough to realize that it's not necessary to denote to
prevent drives from being written to. I was just thinking about two
different roles, primary and secondary.

Having IO freeze on connection loss is enough for me. It solves the
problem. In situation I tried to describe, loosing connection with peer
freezes the primary node. I'm able to log on secondary node, promote it
to primary manually and start necessary services. What will happen in
this situation when connection is re-established? Will former primary
node pick up it's new role as secondary and sync changes?

More information about the drbd-user mailing list