[Fedora-directory-users] Multi-Master Replication Problems

[Ulf Weltman]

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://listman.redhat.com/archives/fedora-directory-users/attachments/20070307/8fd8bbcf/attachment.htm>