db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suresh Thalamati (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 Thu, 07 Jul 2005 22:37:28 GMT
    [ http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12315265 ] 

Suresh Thalamati commented on DERBY-298:
----------------------------------------

Hi Øystein, 

 I could not  understand from the  changes,  If the new log file will be recognized in the
following two cases:
 1)  After the log switch,  if the first log record to the file  gets partially written on
a preallocated log file 
 2) After the log swith , if  the first log write is written out of order incompletely and
the checksum check verification fails.
 
In Scan.java : newFileStart gets set to LogCounter.INVALID_LOG_INSTANT,  immediately 
after reading the instant , but the partial record verification and checksum checks happen
after that and valid  logEnd  value  still refers to previous log file . 

and also  it might  be good idea to make sure all the fields written in the initialization
of  the log file are correct before using the new log file during recovery: initialization
writes 4 fileds seperately , 
whereas verification only looks at 3 fields. 

LogToFIle.java()  : initLogFile() :
newlog.writeInt(fid);
newlog.writeInt(OBSOLETE_LOG_VERSION_NUMBER); // for silly backwards compatibility reason
newlog.writeLong(number);
newlog.writeLong(prevLogRecordEndInstant);

whereas  LogTOFIle: private boolean verifyLogFormat(StorageRandomAccessFile log, longnumber)

which is called before the swicth does not  read/verify  "prevLogRecordEndInstant" . 


Thanks
-suresh
  








> 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