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 "Suresh Thalamati (JIRA)" <de...@db.apache.org> on 2005/10/06 19:24:49 UTC
[jira] Updated: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
[ http://issues.apache.org/jira/browse/DERBY-239?page=all ]
Suresh Thalamati updated DERBY-239:
-----------------------------------
Attachment: onlinebackup.html
functional/design spec based on the input I got on the derby-dev list.
> Need a online backup feature that does not block update operations when online backup is in progress.
> --------------------------------------------------------------------------------------------------------
>
> Key: DERBY-239
> URL: http://issues.apache.org/jira/browse/DERBY-239
> Project: Derby
> Type: New Feature
> Components: Store
> Versions: 10.1.1.0
> Reporter: Suresh Thalamati
> Assignee: Suresh Thalamati
> Attachments: onlinebackup.html
>
> Currently Derby allows users to perfoms online backups using SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure, but while the backup is in progress, update operations are temporarily blocked, but read operations can still proceed.
> Blocking update operations can be real issue specifically in client server environments, because user requests will be blocked for a long time if a
> backup is in the progress on the server.
--
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: [jira] Updated: (DERBY-239) Need a online backup feature that
does not block update operations when online backup is in progress.
Posted by Suresh Thalamati <su...@gmail.com>.
Thanks Øystein. I did not realize, my reply was not going derby-dev.
-suresh
Øystein Grøvlen wrote:
> Suresh,
>
> I guess you got hit by the derby-dev reply-to problem. I guess you
> would want to send your email there.
>
> I agree with what you say here. I think blocking on backup when
> loading jar files are OK. I am currently reviewing your code, and I
> have already seen that you handle the log copying correctly there.
>
> --
> Øystein
>
>
>>>>>>"ST" == Suresh Thalamati <su...@gmail.com> writes:
>
>
> ST> Øystein Grøvlen wrote:
> >>>>>>> "ST(" == Suresh Thalamati (JIRA) <de...@db.apache.org> writes:
> >>
>
> ST> ..<snip>
>
> >> ST(> Attachment: onlinebackup.html
> >> ST(> functional/design spec based on the input I got on the
> >> derby-dev list. Very good spec that seems to cover the necessary
> >> issues. I have a few
>
> >> minor comments:
>
> ST> Thanks for reviewing the spec.
>
> >> - Log files: I would think you may in some cases have to
> >> copy
>
> >> log files from before the backup checkpoint in order to be
> >> able to roll-back transactions that started before the
> >> backup. (Or am I missing something).
>
> ST> No, you are right. Log files before the backup checkpoint are needed
> ST> for rollbacks. I will edit the spec, the correct statement should be:
>
>
> ST> "All the transaction log files starting from the log file that
> ST> contains Undo Low Water Mark of the backup checkpoint to the log file
> ST> that is active at the end of the backup are copied into the backup. "
>
>
>
> >> - Jar files: What if a jar file is stored in the database
>
> >> during backup? Will this be allowed? If yes, how is it
> >> made sure that this is copied into the backup.
>
> ST> Good point. I think jar file actions have to be aware of the parallel
> ST> backup activity and vice versa, otherwise database in the backup can
> ST> possibly get into a consistent state. Because the catalog updates are
> ST> logged, but not the jar files it self, so it is possible that backup
> ST> database catalog(sys.sysfiles) will have a reference to a file that
> ST> does not exist in the backup database.
>
>
> ST> I think this problem can be solved by doing the following:
>
> ST> 1) make backup wait for all jar file activity in progress to complete,
> ST> before copying the jar files from the database to the backup.
>
> ST> 2) make any new jar file activity after the backup of jar files starts
> ST> to wait/fail.
>
>
> ST> I believe jar file action is not very common, so blocking them may not
> ST> be that bad for the users. Window of blocking can be reduced by
>
> ST> copying the jar files after the data segment. If some one thinks
> ST> making jar file requests fail while backup is running is better
> ST> approach, I am ok with it.
>
>
>
> >> - Testing: I think it is important to test that this handles
>
> >> rollback of transactions correctly. There should be a test
> >> that runs with a higher than normal frequency for
> >> transaction rollbacks. - Generally, tests should make
> >> sure that ACID properties are
>
> >> guaranteed after a restore.
> >>
>
>
> ST> Agree with you. I will add tests to cover the above scenarios.
>
>
> ST> Thanks
> ST> -suresht
>
>
>
>
>
>
Re: [jira] Updated: (DERBY-239) Need a online backup feature that
does not block update operations when online backup is in progress.
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
>>>>> "ST(" == Suresh Thalamati (JIRA) <de...@db.apache.org> writes:
ST(> [ http://issues.apache.org/jira/browse/DERBY-239?page=all ]
ST(> Suresh Thalamati updated DERBY-239:
ST(> -----------------------------------
ST(> Attachment: onlinebackup.html
ST(> functional/design spec based on the input I got on the derby-dev list.
Very good spec that seems to cover the necessary issues. I have a few
minor comments:
- Log files: I would think you may in some cases have to copy
log files from before the backup checkpoint in order to be
able to roll-back transactions that started before the
backup. (Or am I missing something).
- Jar files: What if a jar file is stored in the database
during backup? Will this be allowed? If yes, how is it
made sure that this is copied into the backup.
- Testing: I think it is important to test that this handles
rollback of transactions correctly. There should be a test
that runs with a higher than normal frequency for
transaction rollbacks.
- Generally, tests should make sure that ACID properties are
guaranteed after a restore.
--
Øystein