Torsten Schlabach (Tascel eG) wrote:
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.
In regular syncrepl there is no persistent log. In delta-syncrepl yes, there is a persistent log.
The situation you describe would have caused problems for regular syncrepl, but in fact we've got a workaround for that as well.
Regards, Torsten
On Wed, 21 Dec 2011 10:29:08 -0800, Howard Chuhyc@symas.com 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.