Thank you Ulrich and Quanah for you help!

It looks like the '-w' option for slapadd was what I was looking for. When I run 'slapadd -F /etc/openldap/slapd.d -n 2 -w -l setup.ldif', delta syncrepl works as expected.

Since I have finally been able to setup and run in a delta syncrepl MMR configuration, I have found that I no longer have my initial problem where a deleted user is restored! 

Thanks,

Kevin

On Fri, Nov 7, 2014 at 2:00 AM, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>> kevin sullivan <kevin4sullivan@gmail.com> schrieb am 06.11.2014 um 15:14 in
Nachricht
<CAELdiYHrFvZVXCRD96PvP00Hxi2TFJC_GwQM2N=eLAiqBTRuAA@mail.gmail.com>:
> 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 think if your LDIF contains entry UUIDs and CSNs, you can pre-populate the databases; if those are missing, slapadd will create new ones. And if sync works on UUIDs, you'll loose. Am I right?

Regards,
Ulrich

>
> 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 <kevin4sullivan@gmail.com>
> 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 <quanah@zimbra.com>
>> wrote:
>>
>>> --On Friday, October 31, 2014 4:13 PM -0400 kevin sullivan <
>>> kevin4sullivan@gmail.com> 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) $
>>>>
>>>> mockbuild@x86-028.build.eng.bos.redhat.com:/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
>>>
>>
>>