[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Value of contextCSN not persisted
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 <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/