db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
Date Tue, 02 Aug 2005 17:44:28 GMT
o I think it would seem reasonable to leave decision of whether to wait
  for unlogged operations to finish up to the caller of the backup.
  For some set of users waiting is fine, they just want the backup
  eventually, and they are using the feature because they want normal
  users to be impacted as little as possible (at least with respect to
  lock concurrency).  Others may need to know imediately why something
  is blocking their operation.

o I had just assumed that online backup would only work in roll foward
  mode, so there was really no garbage collection anyway - at least not
  until we provide a way to move rollforward logs somewhere
automatically.  I think this is sort of along the lines of what Oystein
is saying, would be good to do in future but 1st impl does not need to
address.  Remember while Derby does not have built in size limits, it
does not have features one expects from VLDB (for really large db's you
probably want to have multiple threads/devices backup up in parallel
along with simultaneous log file moves).



Øystein Grøvlen wrote:

>>>>>>"ØG" == Øystein Grøvlen <Oystein.Grovlen@Sun.COM> writes:
> 
> 
>>>>>>"ST" == Suresh Thalamati <suresh.thalamati@gmail.com> writes:
> 
>     ST> My  initial thought  is to  simply disable  garbage-collection  of log
>     ST> files for the  duration of the backup. unless  there are some specific
>     ST> advantages in writing backup-start log record.
> 
>     ØG> Disabling garabage-collection directly is probably the cleanest way to
>     ØG> do this.
> 
> On second thoughts, for large databases, the time to copy the data
> files may be so long that the log volume becomes prohibitively large
> if garbage collection is turned off for the entire backup.  In that
> case, it would be better to copy finished log files in parallel with
> the data files and let them be garbage collected at any time after it
> has been copied.  This probably does not need to be part of a first
> implementation, but something one should consider for the future.
> 

Mime
View raw message