Hi,
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.
Ludwig
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 -
agmt="cn=masterAgreement1-seattlenfs.bpt.rocks-pki-tomcat"
(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:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Troubleshooting_Replication_Related_Problems.html
"... 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
Shander
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
