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] > <[email protected]> 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@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 > [email protected] <mailto:[email protected]> > http://lists.linbit.com/mailman/listinfo/drbd-user > <http://lists.linbit.com/mailman/listinfo/drbd-user>
_______________________________________________ drbd-user mailing list [email protected] http://lists.linbit.com/mailman/listinfo/drbd-user
