[DRBD-user] How long does it take OOS to clear

G C gcstang at gmail.com
Mon Oct 21 18:19:58 CEST 2019


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 <lists at alteeve.ca> 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 <lists at alteeve.ca
> > <mailto:lists at alteeve.ca>> 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
> >     > drbd-user at lists.linbit.com <mailto:drbd-user at lists.linbit.com>
> >     > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20191021/5ad81bff/attachment.htm>


More information about the drbd-user mailing list