[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Value of contextCSN not persisted

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 Chu<hyc@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.


--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/