[389-users] Multi-Master setup

Rich Megginson rmeggins at redhat.com
Wed Aug 11 14:36:54 UTC 2010


Reinhard Nappert wrote:
> To explain it a bit easier, I define two "methods":
> 1. createAgreement(<remote ldap>):     <-- creates locally replication agreement for remote ldap
> 	nsDS5ReplicaType=3
> 	nsDS5Flags=1
> 	nsDS5ReplicaId=<unique id>
> 	nsDS5ReplicaHost=<hostname of remote ldap>
> 	nsDS5ReplicaTransportInfo=LDAP
>  	nsDS5ReplicaPort=389
> 	nsDS5ReplicaBindDN=<replManager-DN>
> 	nsDS5ReplicaBindMethod=SIMPLE
> 	nsDS5ReplicaCredentials=<replManager-Password>
>
> 2. initReplication(<local ldap>, <remote ldap>):	<-- modifies the existing remote replication agreement for the local ldap
> 	nsds5BeginReplicaRefresh=start
>
> So, the order is the following:
> 1. On A: createAgreement(B)
> 2. On B: createAgreement(A)
> 3. On B: initReplication(B, A)
> 4. On B: createAgreement(C)
> 5. On C: createAgreement(B)
> 6. On C: initReplication(C, B)
> 7. On C: createAgreement(D)
> 8. On D: createAgreement(C)
> 9. On D: initReplication(D, C)
> 10. On D: createAgreement(A)
> 11. On A: createAgreement(D)
> 12. On A: initReplication(A, D)
>   
12 is a problem - you don't initialize the master (A) you started from
> Now, I have the ring A<-->B<-->C<-->D<-->A. All of this works fine!
> Then, I want to create the cross-references from A to C and B to D
> 13. On A: createAgreement(C)
> 14. On C: createAgreement(A)
> 15. On C: initReplication(C, A)
>   
15 is a problem - C has already been initialized
> After step 15, I run into this issue. The same thing happens, when I set B and D up.
> 16. On B: createAgreement(D)
> 17. On D: createAgreement(B)
> 18. On D: initReplication(D, B)
>   
18 is a problem - D has already been initialized
>
> -Reinhard
>
>
> -----Original Message-----
> From: 389-users-bounces at lists.fedoraproject.org [mailto:389-users-bounces at lists.fedoraproject.org] On Behalf Of Rich Megginson
> Sent: Wednesday, August 11, 2010 10:09 AM
> To: General discussion list for the 389 Directory server project.
> Subject: Re: [389-users] Multi-Master setup
>
> Reinhard Nappert wrote:
>   
>> At first I create (besides the changelog and replica entry with nsDS5ReplicaType=3, nsDS5Flags=1 and an unique nsDS5ReplicaId) the shadowing agreement with nsDS5ReplicaHost=<hostname of remote server>, nsDS5ReplicaTransportInfo=LDAP, nsDS5ReplicaPort=389, nsDS5ReplicaBindDN=<replManager-DN>, nsDS5ReplicaBindMethod=SIMPLE, nsDS5ReplicaCredentials=<replManager-Password> on both sides, let's say A and D (A first and then D).
>> Then, I do initiate the replication by setting nsds5BeginReplicaRefresh to start on A.
>>   
>>     
> And you do that for A -> B, A -> C?  How do you initialize D?
>   
>> -Reinhard
>>
>> -----Original Message-----
>> From: 389-users-bounces at lists.fedoraproject.org 
>> [mailto:389-users-bounces at lists.fedoraproject.org] On Behalf Of Rich 
>> Megginson
>> Sent: Tuesday, August 10, 2010 5:57 PM
>> To: General discussion list for the 389 Directory server project.
>> Subject: Re: [389-users] Multi-Master setup
>>
>> Reinhard Nappert wrote:
>>   
>>     
>>> Rich,
>>>
>>> I have an setup like:
>>>
>>>     A <-----> B
>>>    /\ \    / /\
>>>     |  \  /   |
>>>     |   \/    |
>>>     |  / \    |
>>>     | /   \   |
>>>    /\/     \ /\
>>>     D <-----> C
>>>
>>> At first, I do set the agreements up for the Ring A to B to C to B to A. This works. Then, I try to set the cross agreements from A to C and B to D up. This is where I run into this issue.
>>>
>>> Let's have a look how I do those cross agreements. First I add an 
>>> agreement on A for C. This is fine. Then, I do the same on C (for A) 
>>> and I get  the messages NSMMReplicationPlugin - agmt="cn=nix2mustrum" (mustrum:389): Received error 89: NULL for total update operation On C and on A I get:
>>> [10/Aug/2010:17:12:37 -0400] - somehow, there are still 16 entries in 
>>> the entry cache. :/
>>> [10/Aug/2010:17:12:38 -0400] - WARNING: Import is running with 
>>> nsslapd-db-private-import-mem on; No other process is allowed to 
>>> access the database
>>> [10/Aug/2010:17:12:38 -0400] - BAD CACHE ASSERTION at
>>> ../ldap/servers/slapd/back-ldbm/cache.c/765: e->ep_refcnt > 0
>>>
>>>
>>> Hope, this helps.
>>>   
>>>     
>>>       
>> How do you do the replica init?
>>   
>>     
>>> Thanks,
>>> -Reinhard
>>> -----Original Message-----
>>> From: 389-users-bounces at lists.fedoraproject.org
>>> [mailto:389-users-bounces at lists.fedoraproject.org] On Behalf Of 
>>> Reinhard Nappert
>>> Sent: Tuesday, August 10, 2010 2:42 PM
>>> To: General discussion list for the 389 Directory server project.
>>> Subject: Re: [389-users] Multi-Master setup
>>>
>>> Rich, on the consumer, I see the following messages:
>>>
>>> NSMMReplicationPlugin - agmt="cn=nix2mustrum" (mustrum:389): Received 
>>> error 89: NULL for total update operation
>>>
>>> -Reinhard
>>>
>>> -----Original Message-----
>>> From: 389-users-bounces at lists.fedoraproject.org
>>> [mailto:389-users-bounces at lists.fedoraproject.org] On Behalf Of Rich 
>>> Megginson
>>> Sent: Tuesday, August 10, 2010 12:41 PM
>>> To: General discussion list for the 389 Directory server project.
>>> Subject: Re: [389-users] Multi-Master setup
>>>
>>> Reinhard Nappert wrote:
>>>   
>>>     
>>>       
>>>> Hi,
>>>>  
>>>> I have seen the following message in the errors log file, when I set 
>>>> MMR agreements up:
>>>>  
>>>> [10/Aug/2010:11:46:44 -0400] NSMMReplicationPlugin -
>>>> repl_set_mtn_referrals: could not set referrals for replica o=base: 
>>>> 1
>>>> [10/Aug/2010:11:46:44 -0400] NSMMReplicationPlugin -
>>>> multimaster_be_state_change: replica o=base is going offline; 
>>>> disabling replication
>>>> [10/Aug/2010:11:46:46 -0400] - somehow, there are still 20 entries 
>>>> in the entrycache. :/
>>>> [10/Aug/2010:11:46:46 -0400] - WARNING: Import is running with 
>>>> nsslapd-db-private-import-mem on; No other process is allowed to 
>>>> access the database
>>>> [10/Aug/2010:11:46:48 -0400] - BAD CACHE ASSERTION at
>>>> ../ldap/servers/slapd/back-ldbm/cache.c/765: e->ep_refcnt > 0
>>>> [10/Aug/2010:11:46:52 -0400] - Fedora-Directory/1.1.2 B2009.090.1643 
>>>> starting up
>>>> [10/Aug/2010:11:46:52 -0400] - Detected Disorderly Shutdown last 
>>>> time DirectoryServer was running, recovering database.
>>>>  
>>>> After I re-initialize the database from the supplier (setting 
>>>> attribute nsds5BeginReplicaRefresh to start of the agreement 
>>>> object), the database gets correctly imported.
>>>>  
>>>> Any idea, what is going on?
>>>>     
>>>>       
>>>>         
>>> No, not sure.  But if you can develop a reproducible test case, that would be helpful.
>>>   
>>>     
>>>       
>>>> Thanks,
>>>> -Reinhard
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> --
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users at lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>     
>>>>       
>>>>         
>>> --
>>> 389 users mailing list
>>> 389-users at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>> --
>>> 389 users mailing list
>>> 389-users at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>> --
>>> 389 users mailing list
>>> 389-users at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>   
>>>     
>>>       
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>   
>>     
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>   



More information about the 389-users mailing list