You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Øystein Grøvlen (JIRA)" <de...@db.apache.org> on 2005/12/22 12:12:31 UTC
[jira] Commented: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.
[ http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12361100 ]
Øystein Grøvlen commented on DERBY-298:
---------------------------------------
The recently attached patch (derby-298a.diff) addresses Suresh's
review comments. The only major change from the previous patch is in
java/engine/org/apache/derby/impl/store/raw/log/Scan.java. The changes
to this file compared to the current head of trunk are:
- When a new log file is entered, check that the header of this
file refers to the end of the last log record of the previous log
file. If not, stop the scan.
- If the header was consistent, update knowGoodLogEnd to the first
possible LogInstant of this file (end of header).
- close() no longer reset knownGoodLogEnd since it is needed by
FileLogger after the scan is closed.
- Changed comment of getLogRecordEnd() to reflect that it can be
used after the scan is closed, and that it at that time may
return the start of an empty log file.
- Removed comment about not starting to write to the new empty log
file, since that is not true anymore.
In addition, the property files for the tests have been updated so
they are run without the security manager.
derbyall has been run with no new failures.
> 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, derby-298a.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
Re: [PATCH] Re: [jira] Commented: (DERBY-298) rollforward will not
work correctly if the system happens to crash immediately after rollforward
backup.
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I have committed the most recent patch for this issue as svn 367352.
Øystein Grøvlen wrote:
>>>>>>"MM" == Mike Matrigali <mi...@sbcglobal.net> writes:
>
>
> MM> I just got back. I'll look at committing this, but would like to
> MM> wait for Suresh to review.
>
> The new version of the patch, derby-298b.diff, that has been uploaded
> should address issues raised by Suresh in his latest review.
>
Re: [PATCH] Re: [jira] Commented: (DERBY-298) rollforward will not
work correctly if the system happens to crash immediately after rollforward
backup.
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
>>>>> "MM" == Mike Matrigali <mi...@sbcglobal.net> writes:
MM> I just got back. I'll look at committing this, but would like to
MM> wait for Suresh to review.
The new version of the patch, derby-298b.diff, that has been uploaded
should address issues raised by Suresh in his latest review.
--
Øystein
Re: [PATCH] Re: [jira] Commented: (DERBY-298) rollforward will not
work correctly if the system happens to crash immediately after rollforward
backup.
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I just got back. I'll look at committing this, but would like to
wait for Suresh to review.
Øystein Grøvlen wrote:
> I finally got back to this issue hat have been laying around for way
> too long. I have attached a new patch to JIRA that should address
> Suresh's review comments. Could someone please review it?
>
[PATCH] Re: [jira] Commented: (DERBY-298) rollforward will not work
correctly if the system happens to crash immediately after rollforward backup.
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
I finally got back to this issue hat have been laying around for way
too long. I have attached a new patch to JIRA that should address
Suresh's review comments. Could someone please review it?
--
Øystein
>>>>> "ØG" == Øystein Grøvlen (JIRA) <de...@db.apache.org> writes:
ØG> [ http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12361100 ]
ØG> Ãystein Grøvlen commented on DERBY-298:
ØG> ---------------------------------------
ØG> The recently attached patch (derby-298a.diff) addresses Suresh's
ØG> review comments. The only major change from the previous patch is in
ØG> java/engine/org/apache/derby/impl/store/raw/log/Scan.java. The changes
ØG> to this file compared to the current head of trunk are:
ØG> - When a new log file is entered, check that the header of this
ØG> file refers to the end of the last log record of the previous log
ØG> file. If not, stop the scan.
ØG> - If the header was consistent, update knowGoodLogEnd to the first
ØG> possible LogInstant of this file (end of header).
ØG> - close() no longer reset knownGoodLogEnd since it is needed by
ØG> FileLogger after the scan is closed.
ØG> - Changed comment of getLogRecordEnd() to reflect that it can be
ØG> used after the scan is closed, and that it at that time may
ØG> return the start of an empty log file.
ØG> - Removed comment about not starting to write to the new empty log
ØG> file, since that is not true anymore.
ØG> In addition, the property files for the tests have been updated so
ØG> they are run without the security manager.
ØG> derbyall has been run with no new failures.