Quanah,
Thank you for you response again! That seems to make sense, the accesslog DB should not be slapcat-ed and then slapadd-ed to a different server.
Any idea why using slapcat to populate my primary db seemed to cause delta syncrepl MMR to not work? I was starting with a blank accesslog DB and a prepopulated primary DB. When starting slapd on each server (with -d sync), I would see that each server was endlessly looping over every object in their primary DBs and saying that every object was unchanged.
Thanks,
Kevin
On Thu, Nov 6, 2014 at 11:33 AM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On November 6, 2014 at 9:14:31 AM -0500 kevin sullivan < kevin4sullivan@gmail.com> wrote:
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!
Hi Kevin,
The accesslog DB is unique to a given server. You should never slapcat it from one server and slapadd it to another server. It should always start out "blank" on any given new server. The only DB you load between servers is the primary db.
--Quanah
-- Quanah Gibson-Mount Platform Architect Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration