Full_Name: Chris Mikkelson Version: 2.4.23 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37)
I have a multimaster setup, and some read-only slaves mirroring the data with syncrepl. In some circumstances, I've noticed that restarting a slave server leads to a full presentation, even though the masters have an adequately sized sessionlog. This makes refreshOnly synchronization prohibitively expensive.
It appears that the problem is as follows:
The syncprov overlay uses the minimum CSN from the client cookie to decide where to start synchronization, regardless of whether that CSN has changed relative to the same SID's CSN on the provider. For example:
Provider state: CSN: <1 second ago>...#001#... CSN: <1 year ago>.....#002#...
sessionlog mincsn: <1 hour ago>...#001#...
Consumer state: CSN: <1 minute ago>...#001#... CSN: <1 year ago>.....#002#... <-- same as SID 2 CSN on provider
The syncprov overly will take the mincsn from the consumer cookie (the <1 year ago> one above) and compare it to the sessionlog mincsn when deciding whether to do a full presentation. Since the SID 2 CSN hasn't changed in the above example, the consumer is up to date on changes recorded on SID 2, so the SID 1 CSN from the cookie should be used.
To reproduce:
* Set up slapd servers ID 1 and 2 as multimaster nodes, and a third slapd server replicating from server 1.
* Insert one entry into server ID 2, and restart servers 1 and 2.
* Insert entries into Server ID 1.
* Perform enough modifications / deletions on Server ID 1 to cause entries to be purged from the sessionlog (see ITS #6716).
* Wait for slave to catch up, then stop the slave.
* Do any modification on Server ID 1 (only need to change the SID 1 contextCSN)
* Restart slave. Server will present entries to the slave rather than replaying the session log.