[ http://issues.apache.org/jira/browse/DERBY-239?page=comments#action_12361686 ]
Suresh Thalamati commented on DERBY-239: ---------------------------------------- inplace-compress with online backup problem: I was scanning through the code to find out any issues with online backup and in-place compress and came across the following code that does a checkpoint before truncating the container. FileContainer.java: protected void compressContainer( .... // make sure we don't execute redo recovery on any page // which is getting truncated. At this point we have an exclusive // table lock on the table, so after checkpoint no page change // can happen between checkpoint log record and compress of space. dataFactory.getRawStoreFactory().checkpoint(); Above code assumes that redo will only start after the checkpoint done by the compress, that is true in crash-recovery. But restore from backup can start redo from a checkpoint that is taken when backup was started, which can be before the checkpoint done by compress. if compress is run in parallel to the backup, restore from the backup can FAIL because it can not find the pages needed by the redo if a container gets backed up after it is truncate by the compress. I could not think of an easy way to avoid the need for the compress to perform checkpoint while truncating a container. One way to make good online backup when in-place compress is in progress seems to be by enforcing the following restrictions similar to the way unlogged operations are handled: 1) Block in-place compress operation if backup is in progress and 2) Make backup operation wait/fail until compress is done. I don't like to add restrictions, but I guess compress is an infrequent operation, so it may be ok. Any comments/suggestions ? Thanks -suresht > 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: obtest_customer.jar, onlinebackup.html, onlinebackup1.html, > onlinebackup_1.diff, onlinebackup_2.diff, onlinebackup_3.diff, > onlinebackup_4.diff, onlinebackup_5.diff, onlinebackup_6.diff > > 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
