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?