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
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 FreeIPA-users wrote:
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
/Update failed! Status: [2 Replication error acquiring replica:
excessive clock skew]/
I had triple verified that time on both is correct and at most within
seconds of each other.
in dirsrv logs I get
/Excessive clock skew from supplier RUV/
/Unable to acquire replica: error: excessive clock skew/
After doing a bit of searching I found this beauty:
The article mentions that the time skew might occur due to server
being virtualied, and I'm wondering if this is applicable to Amazon.
The steps mentioned in the article look intrusive (and intimidating) .
I'm curious what other avenues are available to me to fix this?
If I blow away the replica and re-set up the new one from scratch
would that fix the problem.
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.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