Quanah, Thank you for the example config earlier. I was finally able to run delta sync replication in an MMR configuration! I was unable to get it to work earlier because I was prepopulating my database via 'slapadd'. Does 'slapadd' not work well with the accesslog overlay? When I started with a blank database and then populated my database via 'ldapadd', the accesslog overlay was properly updated and I was properly able to replicate to my other server.
I am guessing that delta syncrepl was failing for me because my accesslog had no record of the objects in my DIT. Is there a way to prepopulate your DIT and accesslog with 'slapadd' instead of having to us 'ldapadd'? I tried to slapcat my accesslog database and then slapadd it to a blank accesslog database, and that didn't seem to work. After all of this, I still need to see if delta sync replication will solve my original problem of a deleted user being restored! Thanks, Kevin On Fri, Oct 31, 2014 at 4:13 PM, kevin sullivan <[email protected]> wrote: > Thank you very much for the advice and the example config! I generally > convert my slapd.conf to cn=config, I just find it easier to use the > slapd.conf when debugging. But this gives me hope that my problem could be > an issue with the conversion of slapd.conf to cn=config or something that I > can find in your configuration. > > Thank you again, and I will let you know what I find! > > On Fri, Oct 31, 2014 at 3:40 PM, Quanah Gibson-Mount <[email protected]> > wrote: > >> --On Friday, October 31, 2014 4:13 PM -0400 kevin sullivan < >> [email protected]> wrote: >> >> >>> >>> >>> >>> >>> Quanah, >>> >>> Thank you for the suggestion to move to delta-syncrepl MMR. >>> Unfortunately, I am having problems setting this up properly. After >>> reading through some documentation, I thought it would be simple but when >>> I bring up slapd on my two servers, they both start using around 100% CPU >>> and in the debug output the two servers are constantly looping through >>> all of the objects in my DIT and saying that the objects have not >>> changed: >>> >>> 5453d6b5 @(#) $OpenLDAP: slapd 2.4.39 (Jun 18 2014 05:19:18) $ >>> >>> [email protected]:/builddir/ >>> build/BUILD/openldap >>> -2.4.39/openldap-2.4.39/build-servers/servers/slapd >>> 5453d6b5 hdb_monitor_db_open: monitoring disabled; configure monitor >>> database to enable >>> 5453d6b5 slapd starting >>> ... >>> 5453d6b5 syncrepl_message_to_entry: rid=001 DN: dc=example,dc=com, UUID: >>> 1cfcd560-f564-1033-9f47-b521eabdb6ad >>> 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) >>> 5453d6b5 syncrepl_entry: rid=001 inserted UUID >>> 1cfcd560-f564-1033-9f47-b521eabdb6ad >>> 5453d6b5 dn_callback : entries have identical CSN dc=example,dc=com >>> 20141031161001.910968Z#000000#000#000000 >>> 5453d6b5 syncrepl_entry: rid=001 be_search (0) >>> 5453d6b5 syncrepl_entry: rid=001 dc=example,dc=com >>> 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored >>> (dc=example,dc=com) >>> 5453d6b5 syncrepl_message_to_entry: rid=001 DN: >>> ou=users,dc=example,dc=com, UUID: 1cfe8cf2-f564-1033-9f48-b521eabdb6ad >>> 5453d6b5 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) >>> 5453d6b5 syncrepl_entry: rid=001 inserted UUID >>> 1cfe8cf2-f564-1033-9f48-b521eabdb6ad >>> 5453d6b5 dn_callback : entries have identical CSN >>> ou=users,dc=example,dc=com 20141031161001.922234Z#000000#000#000000 >>> 5453d6b5 syncrepl_entry: rid=001 be_search (0) >>> 5453d6b5 syncrepl_entry: rid=001 ou=users,dc=example,dc=com >>> 5453d6b5 syncrepl_entry: rid=001 entry unchanged, ignored >>> (ou=users,dc=example,dc=com) >>> ..... >>> 5453d6b5 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT >>> 5453d6b5 do_syncrep2: rid=001 cookie= >>> ... Repeated forever ... >>> >>> Am I configuring something incorrectly? >>> >>> To refresh your memory, I am running 2.4.39-8. I have two servers >>> (server1 and server2) that I want to setup in delta-syncrepl MMR >>> MirrorMode. >>> >> >> Hi Kevin, >> >> I stopped using the deprecated slapd.conf format years ago, as it's prone >> to misuse and incorrect setup. Your supplied config is an example of why >> it's a bad idea to use slapd.conf (For example, you have serverID under the >> database section, when it's a global option, etc). I'd strongly advise you >> to switch to using cn=config so that you can have an actual validated >> configuration. It also makes troubleshooting a lot easier to do. >> >> Aside from that, your log simply shows the server comparing each entry >> between the two servers... Sounds like they didn't start out believing they >> were in sync and are trying to get there. >> >> Here's an example of my config, using cn=config (slapcat export) minus >> the schema: >> >> <http://pastebin.com/nv1WNX2y> >> >> >> --Quanah >> >> >> >> -- >> >> Quanah Gibson-Mount >> Server Architect >> Zimbra, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > >
