db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.
Date Thu, 26 May 2005 23:25:00 GMT
If possible I would like to see a solution that does not depend on a
special log record being first in the new log.  At the level of specific
log files, it does not know much about log records.  It would be nice if
anything that dealt with log records just saw them as a single sequence
of log records which just happen to be split across multiple files in
this implementation.  Putting stuff in the per log file hdr is fine as
this is specific to this implementation.

Any requirement to put a specific log record "next" in the stream is
likely to cause us to stall all the threads in the system.  Something
missing from your steps is what is going on concurrently in the rest
of the system while this is happening.  I believe currently log records
are being written to the in memory log buffer while the switch is
happening (suresh, is this right?).  Once it goes into the log buffer
it has an address that will make it hard to put a different record
"before" it.

Couldn't step 11 be another bit in the file hdr?

Øystein Grøvlen wrote:

>>>>>>"MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:
>     MM> As you suggest I think there needs to be some way for recovery to
>     MM> determine a successful log switch has happened and to not log to the
>     MM> old file.  I don't think a log record for the switch works as you need
>     MM> to read the log to apply the record, but I think this is problematical
>     MM> as you are trying to determine validity of the log by looging at record
>     MM> in the  log. I  think some  approach as you  and suresh  suggest with
>     MM> markers  in  the  header of  the  individual  log  files is  a  better
>     MM> approach.
> Assuming sync write, the steps to do a log switch is:
> 1. Check if file with next file number exists.  If so, delete it
> 2. Open new log file
> 3. Initialize file (write header) and sync
> 4. Write end marker to old file 
> 5. Flush old file to disk
> 6. Close old file
> 7. Preallocate space in new log file and sync
> 8. Close new file
> 9. Reopen new file in RWS mode
> 10. Go to current end position (after header).
> Basically if a crash occurs before step 3 is finished, the log file
> will just be ignored on recovery because the validation of the header
> fails.  Should it fail after step 3, redo processing will try to
> access the first log rec of the file.  If there is none, the last good
> log record pointer will not be updated and logging will occur in the
> previous file.  This is OK if the crash occurred before the log switch
> was completed since then the operation that initiated the log switch
> would not complete either (e.g., a backup would fail).  As we have
> agreed on, we need something to tell recovery that the log switch was
> completed.
> However, there is currently nothing that prevents recovery from
> interpreting garbage succeeding the header as a log record and
> wrongfully conclude that the log switch was completed.  Even if it is
> not very likely that this would happen, I suggest that to be safe we
> write an integer 0 after the header as part of step 3. In a new step
> 11, we could then write a log switch log record which length would
> overwrite the 0 written in step 3.  This way, depending on during
> which step the crash occurred, the following would happen during the
> redo scan using the existing recovery implementation:
> Crash during step 1 to 3: New file is not valid, continue to use old log file
> Crash during step 4 to 11: New file is empty, continue to use old log file
> Crash after step 11: Process log switch log record, next log record
>                      will be allocated after this record.
> I think this is the behavior we want.

View raw message