[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