db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: [jira] Updated: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
Date Wed, 19 Oct 2005 17:28:17 GMT

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 <suresh.thalamati@gmail.com> writes:
> 
> 
>     ST> Øystein Grøvlen wrote:
>     >>>>>>> "ST(" == Suresh Thalamati (JIRA) <derby-dev@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
> 
> 
> 
> 
> 
> 



Mime
View raw message