IPA crashed and after restarting services seeing "Replica has a different generation ID than the local data." in log
8:06 a.m.
Howdy! Looks like the IPA application crashed on one of our servers (RHEL 6) early this
morning and after restarting it I saw the following in /var/log/dirsrv/slapd-TLD/errors
log:
[18/Oct/2017:07:35:49 -0500] - slapd started. Listening on All Interfaces port 389 for
LDAP requests
[18/Oct/2017:07:35:49 -0500] - Listening on All Interfaces port 636 for LDAPS requests
[18/Oct/2017:07:35:49 -0500] - Listening on /var/run/slapd-TLD.socket for LDAPI requests
[18/Oct/2017:07:35:59 -0500] NSMMReplicationPlugin - agmt="cn=meToidm1.tld
(idm1:389): Replica has a different generation ID than the local data.
[18/Oct/2017:07:36:03 -0500] NSMMReplicationPlugin - agmt="cn=meToidm2..tld"
(idm2:389): Replica has a different generation ID than the local data.
[18/Oct/2017:07:36:03 -0500] NSMMReplicationPlugin - agmt="cn=meToidm1.tld"
(idm1:389): Replica has a different generation ID than the local data.
And that same message appears in the error log on the hosts that have a replication
agreement with this node. And it does not appear to be replicating with the other nodes
as well.
I searched for that message and found:
https://access.redhat.com/solutions/136993
But that implies that this is from a failed install and that is not the same situation.
Any ideas on the best method to clean this up would be appreciated.
Thanks!
8:20 a.m.
New subject: IPA crashed and after restarting services seeing "Replica has a different generation ID than the local data." in log
On 10/18/2017 09:06 AM, john.bowman--- via FreeIPA-users wrote:
Howdy! Looks like the IPA application crashed on one of our servers
(RHEL 6) early this morning and after restarting it I saw the following in
/var/log/dirsrv/slapd-TLD/errors log:
[18/Oct/2017:07:35:49 -0500] - slapd started. Listening on All Interfaces port 389 for
LDAP requests
[18/Oct/2017:07:35:49 -0500] - Listening on All Interfaces port 636 for LDAPS requests
[18/Oct/2017:07:35:49 -0500] - Listening on /var/run/slapd-TLD.socket for LDAPI requests
[18/Oct/2017:07:35:59 -0500] NSMMReplicationPlugin - agmt="cn=meToidm1.tld
(idm1:389): Replica has a different generation ID than the local data.
[18/Oct/2017:07:36:03 -0500] NSMMReplicationPlugin - agmt="cn=meToidm2..tld"
(idm2:389): Replica has a different generation ID than the local data.
[18/Oct/2017:07:36:03 -0500] NSMMReplicationPlugin - agmt="cn=meToidm1.tld"
(idm1:389): Replica has a different generation ID than the local data.
These errors
indicate that the database on the server and remote replica
do not have the same origin. Which means either the replica was not
initialized from this server, or the local db or the remote was
overwritten from a different import. Or perhaps the database got
corrupted if the Directory Server crashed. Either way they are now out
of sync, and you need to reinitialize the replication agreements. The
issue is which direction to initialize replication: idm1 -> idm2 or
idm2 to idm1? You have to figure out which one has the correct/current
data set, then use that server to initialize the other. Once you
initialize the agreements these errors should go away and replication
should work.
And that same message appears in the error log on the hosts that have a replication
agreement with this node. And it does not appear to be replicating with the other nodes
as well.
I searched for that message and found:
https://access.redhat.com/solutions/136993
But that implies that this is from a failed install and that is not the same situation.
Any ideas on the best method to clean this up would be appreciated.
Thanks!
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
8:30 a.m.
New subject: IPA crashed and after restarting services seeing "Replica has a different generation ID than the local data." in log
Fortunately our environment is pretty simple so the choice on which to use was pretty
easy. And sure enough a simple re-init worked like a champ. Thank you very much for the
quick reply!
2376
days inactive
2376
days old
freeipa-users@lists.fedorahosted.org
2 comments
2 participants
participants (2)
-
john.bowman＠zayo.com -
Mark Reynolds