Time skew shouldn't matter tooooo much because of the way that CSN generation works - older clocks are always "pulled up" by the faster clocks as their recieve their CSNs via replication.
Are you specifically seeing an issue because of time skew? Thanks, William, On Mon, 2018-04-09 at 16:11 -0700, Marc Sauton wrote: > this is the correct document for the full cleanup. > it may be possible to recover by just deleting the nsState on a > master and doing a reinit of all the replica, but there may be stale > csn traces in the ruv in each replication agreement. > M. > > > On Mon, Apr 9, 2018 at 5:49 AM, Paul Whitney <paul.whit...@mac.com> > wrote: > > Hi guys, > > > > I have been reading up on a fix for this and only found one set of > > procedures to repair this issue. (http://directory.fedoraproject.or > > g/docs/389ds/howto/howto-fix-and-reset-time-skew.html). Would > > removing/recreating the replication agreement resolve this issue > > instead of the steps in the above URL? > > > > > > Paul M. Whitney > > E-mail: paul.whit...@mac.com > > Sent from my browser. > > > > > > > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject > > .org > > > > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
