Hi Emmanuel Emmanuel Lecharny wrote: > Hi guys, > > as I'm currently working on a recovery tool, I have reviewed the current > configuration we have. Let's first analyse how a recovery tool is good > for and how it should work. > > 1) Usage > ... Makes sense.
> 2) How it should work > ... > (a), or, worse, it occurs while we are writing those modifications, and > now, we can have a totally unstable base (b). > ... > Case (b) is more problematic, because we have no way to determinate > which was the previous stable state (Si), and to restore this state, as > the base has already been partially modified. Does JDBM provide tools to recover the latest stable state? > > What is the solution ? We have to assume that the state Si can be > restored, and that we can apply every modification on it. The only way > to do that is to combine two techniques : > - backup the base on regular basis, assuming that it can be done without > allowing any update on this base during the backup (and this is not > obvious, as the base can be pretty big) > - and store every modification into a journal, to be able to replay them > on the restored base. Do I understand right that you want to write and sync the journal (the changelog LDIF) immediately but the partition only from time to time? I think that makes only sense if writing the journal is cheaper and faster than writing the partition data. Hm, that is similar to journaling file systems, right? > > the N-1 backup). Here is the algorithm : > > Journal last position is N, we have n modifications since then > Spare current base is version N > > - time to apply the journal ! Mark the current position in the journal > as N+1 > - copy the spare base (Spare-N) to Spare-(N+1) > - apply the journal from position N to position N+1 > - if everything is ok, tell the system that the current backup base is > Spare-(N+1) and that the current log position is N+1 Ideally this should be an atomic operation. Sound good. Regards, Stefan
