Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> You usually leave S disconnected, that's why you need a full sync to > bring S up to speed, but normally what you would do when using stacked > resources would be to configure S with protocol A, this is actually the > recommendation in the drbd.org docs > http://www.drbd.org/users-guide/s-three-nodes.html#s-three-node-config Actually, this is only valid when 1. the third node is to stay in permanent sync and 2. there is a WAN link in between the third node and its peers If the RTT is reasonably low, Protocol C is not supposed to be much slower than A and stacking absolutely doesn't require Protocol A. Also note that S never needs a full sync, unless you manage to break the UUIDs on A and B. Normally, upon reconnecting, S will do a quicksync. > You need A->B, and you can only setup one replication link that spans 2 > servers (e.g.: you can't set A's /dev/drbdx to replicate to both B and S > at the same time), the only way to do it is to set normal A->B, and on > top of that AB->S, because you don't know if A or B will be up and don't > want to manually choose (if it was somehow possible) to sync A->S or > B->S depending on which (A or B) is up. Stacked resources does that for > you automagically, it syncs whomever is Primary to the stacked resource (S). To answer the base concern: No, you cannot just reconfigure S to be an unstacked peer for A or B (unless a full sync is OK for you). That's because S does not share UUIDs with the resource replicated among A and B. You can however leave the stacking in place on the surviving node (A or B) and remain in a configuration of A: (StandAlone/Primary) (Connected/Primary) S: (------------------) (Connected/Secondary) where your normal configuration is A: (Connected/Primary) (WFConnection/Primary) B: (Connected/Secondary) (--------------------) S: (-------------------) (Standalone/Secondary) I hope this sketch is comprehensible. Cheers, Felix