[DRBD-user] Inconsistent primary and UpToDate Secondary

Kushnir, Michael (NIH/NLM/LHC) [C] michael.kushnir at nih.gov
Fri May 29 16:57:03 CEST 2015

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


So, you think it is safe to fail over to the secondary even though the primary is inconsistent? How can a primary be inconsistent when it is the one taking the writes?


From: Ben RUBSON [mailto:ben.rubson at gmail.com]
Sent: Thursday, May 28, 2015 12:24 PM
To: drbd-user at lists.linbit.com
Subject: Re: [DRBD-user] Inconsistent primary and UpToDate Secondary


If sda1 is a LSI RAID adapter (you talk about MegaCLI), I would run a PatrolRead (and a ConsistencyCheck) to be sure the backend is OK.

Then, when the secondary is in a inconsistent state, usually a disconnect / connect repairs the situation.
I would say that you have to failover in order to repair the situation.
1 - Failover
2 - Then check your backend
3 - Disconnect r0 / Connect r0
4 - drbdadm verify r0

Let’s wait for a confirmation from others.



Le 28 mai 2015 à 18:00, Kushnir, Michael (NIH/NLM/LHC) [C] <michael.kushnir at nih.gov<mailto:michael.kushnir at nih.gov>> a écrit :

I have an interesting situation that I am not sure how to fix:

From /var/log/messages:

May 27 09:09:55 XXXXX kernel: block drbd0: local READ IO error sector 8176113434+256 on sda1
May 27 09:09:55 XXXXX kernel: block drbd0: Local IO failed in __req_mod.
May 27 09:09:55 XXXXX kernel: block drbd0: disk( UpToDate -> Inconsistent )
From /etc/init.d/drbd status:

drbd driver loaded OK; device status:
version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by phil at Build64R6, 2014-10-28 10:32:53
m:res  cs         ro                 ds                     p  mounted  fstype
0:r0   Connected  Primary/Secondary  Inconsistent/UpToDate  C

Primary is mounted and shared out over NFS. NFS share is taking reads and writes. MegaCLI reports no RAID or disk errors.

Is the primary reading and writing form the secondary at this point?

What is the best course of action to correct the situation?

Is the secondary truly up to date, or should I force a resync from the active primary?


drbd-user mailing list
drbd-user at lists.linbit.com<mailto:drbd-user at lists.linbit.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20150529/586e6541/attachment.htm>

More information about the drbd-user mailing list