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@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxxx >> [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxxx >>> [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxxx >>> [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxxx >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>>> >>>> >>> -- >>> 389 users mailing list >>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> -- >>> 389 users mailing list >>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> -- >>> 389 users mailing list >>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >>> >>> >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
