(ITS#6717) syncprov performs unnecessary presentations/refreshes.

[cmikk@qwest.net]

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.