Reinhard Nappert wrote: > Rick, > > Are you saying that, once I have replicated the data from A to B and from B > to C and from C to D, I don't replicate it from D to A? If so, can you > explain why? Anyway, this step works! > If you replace the word "replicated" with "initialized", then yes, you don't initialize from D to A. Although it may work, I think it may introduce subtle errors, such as the ones you see. > So, 15 and 18 are up-to-date at this stage. Since the entire setup is done > kind of automatically, the setting of nsds5BeginReplicaRefresh to start is > always done, if the corresponding agreement exists on the remote box. Is > there a way to find out when I have to set nsds5BeginReplicaRefresh to > start? > > In any case, this does not explain that I fix the issue by resetting > nsds5BeginReplicaRefresh to start, once I run into this issue. > I'm not exactly sure why you are seeing the errors you are seeing, nor why you can fix the issue with start refresh. I do know that you should not re-initialize a server that has been used to initialize other servers. > -Reinhard > > -----Original Message----- > From: 389-users-boun...@lists.fedoraproject.org > [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Rich Megginson > Sent: Wednesday, August 11, 2010 10:37 AM > To: General discussion list for the 389 Directory server project. > Subject: Re: [389-users] Multi-Master setup > > 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-boun...@lists.fedoraproject.org >> [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org >>> [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org >>>> [mailto:389-users-boun...@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-boun...@lists.fedoraproject.org >>>> [mailto:389-users-boun...@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-us...@lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> 389 users mailing list >>>> 389-us...@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> -- >>>> 389 users mailing list >>>> 389-us...@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> -- >>>> 389 users mailing list >>>> 389-us...@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>>> >>>> >>>> >>> -- >>> 389 users mailing list >>> 389-us...@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> -- >>> 389 users mailing list >>> 389-us...@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >>> >>> >> -- >> 389 users mailing list >> 389-us...@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-us...@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> > > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users >
-- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
