replication uses CSNs(change sequence numbers) to synchronize data
across the topology, and it requires the times to be in sync and
that time never goes backward, otherwise a new change would get an
older csn and probably be ignored after repliciation.
Since it is not guaranteed that system time is always is sync and
that no one plays with the time setting, replcation uses its own csn
state, maintainig the local system time and remote or local offsets
when differnces in time were detected. This ensures that time is in
sync, as good as possible, and that time never goes backward.
Unfortunately these offsets can accumulate over time and reach a
value where replication "thinks" it is insane to continue and raises
the clock skew error.
In my opinion this should not be a fatal error, but right now it is,
feel free to log an RFE.
Now, the csns are part of all the individual data in the servers's
database, so you cannot just clean them up, also if you add a new
replica it will inherit the offsets present in other servers.
Unfortunately I only see the hard way to get out of this: export the
data without state information(csns), reimport and reinitialize.
That's in the doc you referenced
On 06/01/2017 09:29 PM, pgb205 via
I have noticed
that we had a broken replication agreement between replica in
amazon and on another physical node.
I have attempted
to re-initialize but received
Status: [2 Replication error acquiring replica: excessive
triple verified that time on both is correct and at most
within seconds of each other.
dirsrv logs I get
skew from supplier RUV
Unable to acquire
replica: error: excessive clock skew
doing a bit of searching I found this beauty:
mentions that the time skew might occur due to server being
virtualied, and I'm wondering if this is applicable to
mentioned in the article look intrusive (and intimidating) .
I'm curious what other avenues are available to me to fix
blow away the replica and re-set up the new one from scratch
would that fix the problem.
FreeIPA-users mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander