Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mar 23, 2010, at 9:16 AM, Lars Ellenberg wrote: > On Mon, Mar 22, 2010 at 09:39:00AM -0500, Alex Dean wrote: >> I'm using drbd 3.3.7 + heartbeat 3. I've configured dopd using >> http://www.drbd.org/users-guide/s-heartbeat-dopd.html. It works as >> expected. If I pull the ethernet cable used for drbd replication, I >> see dopd activity in heartbeat's logs, and the secondary's dstate >> changes to 'Outdated'. >> >> Is it somehow possible to force drbd to become primary with this >> outdated data? I'm thinking if there is an unnoticed (failure of >> monitoring, perhaps?) failure of the replication link, and then >> there is some catastrophic failure on the primary which renders its >> data unusable, it might be preferable to go forward with promoting >> the outdated secondary to primary status. I understand this means >> lost data. >> >> I've been reading through the man pages for drbdadm and drbdsetup, >> as well as the DRBD Users Guide, and haven't found anything >> describing how to do this. Can it be done? > > Prior to 8.3.8, you'd have to fiddle with drbdmeta set-gi. > Starting with drbd 8.3.8 (which has not been released yet, > so read "current git", if you like) a simple --force primary > will do. Thanks for the reply. I've configured dual NICs for DRBD replication in active/passive bonding, so I think the hypothetical situation I described is unlikely. But I've seen other 'unlikely' things occur. Just trying to think through what the failure scenarios are, and how we'd recover from them. alex -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100323/cef090c5/attachment.pgp>