you get the "different database generation" if one side is built from scratch or reimported from a plain ldif without repl stat e information. replication will only work if both sides have the same data origin.

About initlializing back and forth it depends on your topology if it can become a problem. If a replica is reinitialized it's changelog is recreated (the old one will no longer match) and if you do it again in the other direction you remove the changelog there as well - and then can msis changes not yet replicated to other replicas and you can run into the "csn not found problems".

I looked up one of your previous posts about which version of 389-ds you are using, and it looks like you have one we know has some issues, as stated several times on this list :-(

About your observation that replication is stopping and working again after restarting, this can be a problem of the replication agreement going into fatal state instead of retrying. Restarting the server overcomes this, but you could achieve it by disabling the agreement.


On 10/11/2016 06:13 PM, Ian Harding wrote:
I have this error in the log of my FreeIPA server freeipa-sea.bpt.rocks:

[11/Oct/2016:09:04:39 -0700] NSMMReplicationPlugin -
(seattlenfs:389): The remote replica has a different database generation
ID than the local database.  You may have to reinitialize the remote
replica, or the local replica.

So I did this:

ipa-replica-manage re-initialize --from freeipa-sea.bpt.rocks

on seattlenfs

But the error continues.

I think I know why.  freeipa-sea had a meltdown and I had to rebuild it,
and established it as a replica of seattlenfs.  Unfortunately, I think
seattlenfs was a replica of the original freeipa-sea.

It seems like a bad idea to reinitialize themselves from each other, and
in fact it's warned against here:


"... Also, M2 should not initialize M1 back."

But in looking at my bash history I have indeed done that as well.

Is there any way out of this mess?  These two servers actually DO
replicate, most of the time.  They stop for no reason and restarting the
ipa services on freeipa-sea does get them started again.

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 

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to