version: 8.4.10 Ran the resume-sync all and received: 0: Failure: (135) Sync-pause flag is already cleared Command 'drbdsetup-84 resume-sync 0' terminated with exit code 10
Protocol used is 'A', our systems are running on a cloud environment. On Mon, Oct 21, 2019 at 9:09 AM Digimer <[email protected]> wrote: > 8.9.2 is the utils version, what is the kernel module version? > (8.3.x/8.4.x/9.0.x)? > > It's possible something paused sync, but I doubt it. You can try > 'drbdadm resume-sync all'. The oos number should change constantly, any > time a block changes it should go up and every time a block syncs it > should go down. > > What protocol are you using? A, B or C? > > digimer > > On 2019-10-21 11:31 a.m., G C wrote: > > I'm seeing OOS not being cleared for many days if not weeks, i.e. the > > OOS number stays the same. > > > > Is there a way to tell if the blocks that are OOS are changing or if > > it's the same ones that are just taking a very long time to sync with > > the secondary? > > > > Version: 8.9.2 > > > > On Mon, Oct 7, 2019 at 7:55 AM Digimer <[email protected] > > <mailto:[email protected]>> wrote: > > > > Out of Sync is a question of what has changed locally versus what has > > reached the peer. It seems like you're generating changes on the > Primary > > faster than the Secondary can receive them. So one answer is to > speed up > > your replication link and/or the speed of the storage on the > Secondary, > > depending on which is the bottle-neck. > > > > The other option is to switch to "Protocol C", which tells DRBD to > not > > consider a write complete until it has reached both nodes. This will > > effectively slow down your Primary node's storage to whatever speed > the > > Secondary can be written to, however, and may not be acceptable in > your > > use case (see back to point 1 above). > > > > digimer > > > > On 2019-10-07 10:40 a.m., G C wrote: > > > I have an instance that seems to get OOS down lower and once in a > > while > > > it hits 0 but not very often. Typically my oos is about > > 180000-200000, > > > is there a way to clear this outside of the verify which takes a > long > > > time? Is there something deeper I can dig into that would stop > > the oos > > > from occurring? > > > > > > Thank you > > > > > > > > > > > > _______________________________________________ > > > Star us on GITHUB: https://github.com/LINBIT > > > drbd-user mailing list > > > [email protected] <mailto:[email protected]> > > > https://lists.linbit.com/mailman/listinfo/drbd-user > > > > > > > > > -- > > Digimer > > Papers and Projects: https://alteeve.com/w/ > > "I am, somehow, less interested in the weight and convolutions of > > Einstein’s brain than in the near certainty that people of equal > talent > > have lived and died in cotton fields and sweatshops." - Stephen Jay > > Gould > > > > > -- > Digimer > Papers and Projects: https://alteeve.com/w/ > "I am, somehow, less interested in the weight and convolutions of > Einstein’s brain than in the near certainty that people of equal talent > have lived and died in cotton fields and sweatshops." - Stephen Jay Gould >
_______________________________________________ Star us on GITHUB: https://github.com/LINBIT drbd-user mailing list [email protected] https://lists.linbit.com/mailman/listinfo/drbd-user
