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 Tue, 24 May 2005 13:57:10 GMT
     [ http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_66168 ]
     
Øystein Grøvlen commented on DERBY-298:
---------------------------------------

Looking at the code, I became a bit confused about the definition of an empty log file.  
Scan.getNextRecordForward contains debug output when it detects an empty log file.  It will
then return without setting knownGoodLogEnd.  Hence, new log records will be written to the
end of the previous file.  As Suresh says this is probably to be able to handle crashes during
log switch.

However, this is not what happens when I run the recovery part of the example in this report.
 Since, currentLogFileLength is a large number, it detects "zapped log end on log file", goes
on to the next file, which does not exist, and returns.  (Who sets the length of a log file?
 Is this maximum size until a log switch is performed?)  The effect is the same, but this
can not be used to detect an empty log file and apply the solution proposed by Suresh.  Instead,
one would have to do some hairy file handling at a later stage.

An alternative way to fix this would be to just create a dummy log record in the new log file
as part of the backup command.  This would make the redo scan end in the new log file.  However,
this will not work for those who do backup with OS-commands (i.e., copy the files directly).

I would also think it should be possible to do the log switch in such a way that it is possible
to detect during recovery whether the log switch had completed or not.  If this was the case,
one could just set knownGoodLogEnd of the redo scan to the start of the empty file if the
log switch was completed.  Does anyone know if this is possible?




> 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

>
> 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