[DRBD-user] Inconsistent primary and UpToDate Secondary

Digimer lists at alteeve.ca
Fri May 29 17:15:25 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 long as DRBD has access to the UpToDate peer, it can read from there
if it is asked to read inconsistent blocks. In this way, where a service
resides is independent of which node is UpToDate.

If, however, the UpToDate peer goes offline, the Inconsistent peer will
immediately demote to Secondary, rendering it useless. For this reason,
though it is possible to run on the Inconsistent node, it doesn't make a
lot of practical sense.

On 29/05/15 10:57 AM, Kushnir, Michael (NIH/NLM/LHC) [C] wrote:
> Ben,
> 
>  
> 
> 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?
> 
>  
> 
> Thanks,
> 
> Michael
> 
>  
> 
> *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
> 
>  
> 
> Hello,
> 
>  
> 
> 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.
> 
>  
> 
> Regards,
> 
>  
> 
> Ben
> 
>  
> 
>  
> 
>  
> 
>     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?
> 
>      
> 
>      
> 
>      
> 
>     Thanks,
> 
>     Michael
> 
>      
> 
>      
> 
>      
> 
>      
> 
>     _______________________________________________
>     drbd-user mailing list
>     drbd-user at lists.linbit.com <mailto:drbd-user at lists.linbit.com>
>     http://lists.linbit.com/mailman/listinfo/drbd-user
> 
>  
> 
> 
> 
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
> 


-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?



More information about the drbd-user mailing list