Howard! > In fact the syncprov overlay always reads the largest entryCSN out of the > database at startup time anyway, so even if it didn't save the contextCSN > before stopping, it will be up to date on every startup.
I wonder how that works if the last operation before the unclean shutdown has been a delete operation? IIUC, then on a delete, the contextCSN is updated but you would have to read the deleted entry upon the next startup to get the contextCSN back, wouldn't you? I didn't actually try it, but I bet that in the discussed scenario, i.e.: - delete an entry from master - replicate deletion to slaves - master crashes - master is restarted you would end up with a "slave newer than master" kind of situation, which IIUC, is considered an error, isn't it? Or do you keep a log of operations (which is persisted immediately / timely) which syncprov may read also upon startup to learn about the delete operation and the resulting contextCSN? If you just scan for the still existing entry with the largest entryCSN number, you will detinitely end up with a to low contextCSN of the master in case of the above scenario IMO. Regards, Torsten On Wed, 21 Dec 2011 10:29:08 -0800, Howard Chu <[email protected]> wrote: > Torsten Schlabach (Tascel eG) wrote: >> Hi Quanah! >> >> First of all: Thanks for answering the original question. I was wondering >> first why changes to the database content as such have been persisted and >> the new contextCSN hasn't until I found that this syncprov-checkpoint >> thing >> actually belongs to the syncprov overlay. So I guess it makes sense to >> switch that on as otherwise - for example after a power failure - I would >> have lost information, wouldn't I? > > No, of course not. If there was a danger of data loss we certainly would > not > leave that as the default behavior. > > In fact the syncprov overlay always reads the largest entryCSN out of the > database at startup time anyway, so even if it didn't save the contextCSN > before stopping, it will be up to date on every startup. Checkpointing the > CSN > is only an optimization, it will reduce the length of the search time on > the > next startup. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/
