[DRBD-user] recover from a situation

Pavlos Parissis pavlos.parissis at gmail.com
Sat Sep 25 19:37:34 CEST 2010

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

On 24 September 2010 20:43, Lars Ellenberg <lars.ellenberg at linbit.com>wrote:

> On Fri, Sep 24, 2010 at 02:35:04PM +0200, Pavlos Parissis wrote:
> > Hi,
> >
> > Here is a situation from which I want either automatic (by the cluster)
> or
> > manually (by the admin) to recover from.
> >
> > DRBD resource runs on node 1
> > shutdown all nodes in a such order which will not cause a failover of the
> > resources
> > start the node 2 which was secondary prior the shutdown.
> >
> > As we know DRBD wont let the cluster to start up the drbd resource
> because
> > is marked outdated.
> > what would be the correct way to recover from this situation?
> If I understand correctly, your scenario is that the only data left is
> an outdated secondary, you have catastrophically lost the good data at
> the Primary site.

You understood correctly.

> The Outdated one will refuse to be promoted.
> That is easily changed by drbdadm -- --force primary $resoucename.

I found this related thread
where it is mentioned to use --overwrite-data-of-peer, isn;t it necessary
I guess when the old primary is back online his data will be overwritten

(older drbd versions may need to low-level modify the metadata
> with drbdmeta show-gi/set-gi).
> You should definetly not automate this, as it would render all the
> effort we do to "outdate" disconnected secondaries useless.

OK, I understand the reasons.

Thanks for your reply,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100925/6fdeb4d8/attachment.htm>

More information about the drbd-user mailing list