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] Updated: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.
Date Mon, 04 Jul 2005 10:26:11 GMT
     [ http://issues.apache.org/jira/browse/DERBY-298?page=all ]

Øystein Grøvlen updated DERBY-298:
----------------------------------

    Attachment: derby-298.diff

The attached patch fixes the bug by setting the logEnd after recovery to the beginning of
the new empty log file instead of the end of the previous file. 
The patch contains changes to the following files:

M      java/engine/org/apache/derby/impl/store/raw/log/FileLogger.java
        - At the end of the redo scan, if the scan stopped in a file succeeding the file of
the last log record, update logEnd to this position.
        - Change assert to allow logEnd to be in a newer file than that of the last log record.
         
M      java/engine/org/apache/derby/impl/store/raw/log/Scan.java
        - Introduced new variable newFileStart which will only have a valid LogInstant value
when the scan is at the header of the file.
        - When a new file is entered, set newFileStart to the first  possible LogInstant of
this file (end of header).
        - When a log record is encountered, set newFileStart to INVALID_LOG_INSTANT.
        - Changed getLogRecordEnd() to return newFileStart if that is valid (i.e., scan is
at the start of a file)
        - Removed comment about not starting to write to the new empty log file, since that
is not true anymore.

A      java/testing/org/apache/derbyTesting/functionTests/tests/store/RecoveryAfterBackup_app.properties
         - Test properties

M      java/testing/org/apache/derbyTesting/functionTests/tests/store/copyfiles.ant
         - Added new property files

A      java/testing/org/apache/derbyTesting/functionTests/tests/store/RecoveryAfterBackupSetup_app.properties
        - Test properties. 
        - useextdirs=true needed so the backup is placed somewhere the next test can find
it.

A      java/testing/org/apache/derbyTesting/functionTests/tests/store/RecoveryAfterBackup.java
        - Test that is supposed to be run after RecoveryAfterBackupSetup.java.
        - Does recovery, updates the database, shutdowns the database, and does roll-forward
restore.
        - Checks that updates made after recovery is reflected in the database after roll-forward
restore.

A      java/testing/org/apache/derbyTesting/functionTests/tests/store/RecoveryAfterBackupSetup.java
        - Test that does the preparation for the RecoveryAfterBackup test.
        -  Inserts a few records, makes a backup, and stops without shutting down.

M      java/testing/org/apache/derbyTesting/functionTests/harness/RunTest.java
        - For tests where the database is not deleted at the end of the test, do not delete
the external directories either.
        - This is necessary to be able to access the backup in suceeding tests.

A      java/testing/org/apache/derbyTesting/functionTests/master/RecoveryAfterBackupSetup.out
        - Test output

A      java/testing/org/apache/derbyTesting/functionTests/master/RecoveryAfterBackup.out
        - Test output

MM     java/testing/org/apache/derbyTesting/functionTests/suites/storerecovery.runall
        - Added tests to storerecovery suite.
        - Changed property eol-style.


> 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