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 Tue, 24 May 2005 23:13:37 GMT
I spent some time thinking about this and I think the dummy record
approach works in the current system assuming the code is as follows:

o request for roll forward backup starts
o all subsequent write requests suspended
o log switch initiated by backup request
o dummy record written
o backup takes place, any failure during backup somehow marks backup as
failed.
o backup succeeds, rest of system is allowed to continue writing.

Will a similar approach work when we support real online backup, where
threads are allowed to continue writing to the log files during the
backup?

Also at some point we should be allowing copies of each log file as it
is finished - or at least as some unit of work is finished - maybe log
file, maybe checkpoint. In that case would we need to write a dummy
record in every file?

Øystein Grøvlen (JIRA) wrote:
>      [ http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_66209 ]
>      
> Øystein Grøvlen commented on DERBY-298:
> ---------------------------------------
> 
> On second thoughts, recovery after an OS-command backup is not an issue since the database
will be shut down when the backup is  performed.  So, why not insert a "dummy" record in the
new log file when doing backup?  Then, no changes would be needed to the recovery mechanism.
> 
> 
> 
>>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
> 
> 

Mime
View raw message