db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.
Date Fri, 15 Jul 2005 13:28:12 GMT
    [ http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12315919 ] 

Øystein Grøvlen commented on DERBY-298:
---------------------------------------

Suresh,

The intent is that the new log file should be recognized after a log switch, regardless of
what log records may have been written after this log switch. I see your point that if the
log file contains a single corrupt record,  the log switch will not have an effect since newFileStart
has been reset and logEnd has not been advanced to the new file.  Thanks for detecting this.

My suggestion for fixing this, is to drop the introduction of newFileStart and just update
logEnd to the start of the new log file when the log file is detected.  In addition, logEnd
must not be reset to INVALID_LOG_INSTANT when a scan is closed.  This way it is possible to
get the logEnd after the scan is closed and check whether it has been advanced since the last
log record was processed.

For the verification of prevLogRecordEndInstant, I guess that the best is to verify this for
all files processed during recovery.  I assume that the prevLogRecordEndInstant of a file
should be equal to the current logEnd when switching to this file. 

Thanks for the advice, I will create a new patch.
 
Øystein

> rollforward will not work correctly  if the system happens to crash immediately after
rollforward backup.
> ---------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-298
>          URL: http://issues.apache.org/jira/browse/DERBY-298
>      Project: Derby
>         Type: Bug
>   Components: Store
>     Versions: 10.0.2.1
>     Reporter: Suresh Thalamati
>     Assignee: Øystein Grøvlen
>     Priority: Minor
>  Attachments: derby-298.diff
>
> If the system crashes after a rollforward backup; last log file 
> is empty(say log2.dat). On next crash-recovery system ignores the  empty log 
> file and starts writing to the previous log(say log1.dat),  
> even thought there was successfule log file switch  before the crash.
> The reason I belive it is done this way to avoid special 
> handling of crashes  during the log switch process. 
> Problem is  on rollfroward restore from a backup log1.dat will get overwritten 
> from the copy in the backup, so any transaction that got added to log1.dat
> after the backup was taken will be lost. 
>  
> One possible solution that comes to my mind to solve this problem is 
>  1) check if an  empty a log file exist after a redo crash-recovery , if 
>      the log archive mode is enabled.
>  2) If it exists , delete and do log file switch again 
>  
> Repro:
> connect 'jdbc:derby:wombat;create=true';
> create table t1(a int ) ;
> insert into t1 values(1) ;
> insert into t1 values(2) ;
> call SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(
>     'extinout/mybackup', 0);
> --crash (NO LOG RECORDS WENT IN AFTER THE BACKUP).
> connect 'jdbc:derby:wombat';
> insert into t1 select a*2 from t1 ;
> insert into t1 select a*2 from t1 ;
> insert into t1 select a*2 from t1 ;
> insert into t1 select a*2 from t1 ;
> insert into t1 select a*2 from t1 ;
> insert into t1 select a*2 from t1 ;
> insert into t1 select a*2 from t1 ;
> select count(*) from t1 ;
> --exit from jvm and restore from backup
> connect
> 'jdbc:derby:wombat;rollForwardRecoveryFrom=extinout/mybackup/wombat';
> select count(*) from t1 ;  -- THIS WILL GIVE INCORRECT VALUES

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message