I'd love to know how your RUV could be missing. I wonder if whatever problem left you with mismatched generation ID still persists, it seemed odd that happened after a network outage. If the RUV entry was missing that would explain it, that's where the generation ID of the local data is stored. Did you get replication running again? Do your masters have updates that need to be merged? If they're in sync or are only diverged by testing-related updates, I would try... back up my two masters, for potential restore or future investigation (db2bak) export one master to LDIF without -r (db2ldif) import that LDIF into the same master (ldif2db) perform the search for the RUV entry to make sure its created this time after the import completes (ldapsearch for the magic nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff entry) initialize the other master, either via online initialization or LDIF with -r (db2ldif -r) And if you can determine how you ended up in the state where the RUV is missing, post at bugzilla.redhat.com Wendt, Trevor wrote: > "Can you show us the RUV from the server that produces the csnplCommit > error?" > All I get is "ldap_search: No such object" > > Replica Configuration -- in it's current state. > version: 1 > dn: cn=replica,cn="dc=<mydomain>,dc=com",cn=mapping tree,cn=config > objectClass: nsDS5Replica > objectClass: top > nsDS5ReplicaRoot: dc=<mydomain>,dc=com > nsDS5ReplicaType: 3 > nsDS5Flags: 1 > nsDS5ReplicaId: 1 > nsds5ReplicaPurgeDelay: 604800 > nsDS5ReplicaBindDN: uid=<RepUserId>,cn=config > cn: replica > nsState:: AQAAAAQh7kUAAAAAAAAAAAEAAAA= > nsDS5ReplicaName: 1848ed03-1dd211b2-808393a4-a3ae0000 > nsds5ReplicaChangeCount: 41 > nsds5replicareapactive: 0 > > > > -----Original Message----- > >> "The generation ID errors sound like real errors, but those should be >> resolvable with the correct replica re-initialization done." >> >> I've tried re-initializing the consumer multiple times with no >> > success. > >> The NSMMReplicationPlugin - replica_check_for_data_reload and the >> > "csn" > >> errors are on my supplier server. When my srv2 went offline my srv1 >> became the "Master" so I can't go from srv2 to srv1 without losing >> entries. This is the dilemma... >> >> Thanks for you're suggestions. Please, keep them coming. >> >> > Can you show us the RUV from the server that produces the csnplCommit > error? > ldapsearch -x -D "cn=directory manager" -W -s base -b > "nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=<mydomain>,dc=com" > "(&(objectclass=*)(objectclass=nstombstone))" > > And your replica configuration? > ldapsearch -x -D "cn=directory manager" -W -b "cn=config" > "(objectclass=nsds5replica)" > > ####### > REF: > https://www.redhat.com/archives/fedora-directory-users/2007-March/msg000 > 20.html > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20070307/8fd8bbcf/attachment.html
