Ben Poliakoff wrote:
Somehow the contextCSN of my accesslog wasn't in sync with the
contextCSN of my primary db on master or my replica; master and replica
agreed on the contextCSN for the primary db, but the contextCSN for
the accesslog on my master was off. This explains the symptoms I was
seeing: I could sync the entire primary db to my slave, but trouble
ensued once the slave started to look at the accesslog (due to the
conflicting contextCSNs).
Once I got the contextCSNs in sync (by making a trivial modification to
an entry in my primary db) things got a lot happier. I need to figure
out how I managed to get the contextCSNs out of sync in the first place.
In your first post you mentioned that you had just freshly loaded the
main DB. If you did that using slapadd, from an LDIF that didn't include
the entryCSN operational attribute, then that means the main DB had to
generate all new CSNs for everything. That would certainly cause it to
get way off from the log DB.
Thanks again for your help, it was right on the mark.
And once again as someone new to syncrepl and delta syncrepl, I just
have to saw "Wow!". Delta syncrepl is *very* cool both in design and in
practice. Updates to slaves are exceedingly fast. Thanks to all the
devs and bug reporters for bringing OpenLDAP to where it is today.
Anything to get rid of slurpd.... I wonder how many lines of original
UMich code are left in the server, can't be that many...
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
