db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Commented: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
Date Fri, 22 Jul 2005 09:26:33 GMT
Suresh Thalamati (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-239?page=comments#action_12316434 ]

> Suresh Thalamati commented on DERBY-239:
> ----------------------------------------

[comments just on this issue]

> b) read each pages in to the page cache first and then  latch  the
>    page in the cache until a  temporary copy of it is made. This approach
>    does not have extra overhead of extra latches on the page keys during writes , but

>    will pollute the page cache with the pages that are only required by the 
>    backup; this  might have  impact on user operations because active user pages may

>    have been replaced by the backup pages in the page cache. 
> or 
> c) read pages into buffer pool and latch them while making a copy  similar to
> the above approach,  but some how make sure that user pages are not kicked out 
> of the buffer pool.

I think b) is the correct approach, but what is 'buffer pool' in c)?

I think modifications to the cache would be useful for b), so that
entries in the cache (through generic apis, not specific to store) could
mark how "useful/valuable" they are. Just a simple scheme, lower numbers
less valuable, higher numbers more valuable, and if it makes it easier
to fix a range, e.g. 0-100, then that would be ok. Then the store could
added pages to the cache with this weighting, e.g. (to get the general idea)

     pages for backup - weight 0
     overflow column pages - weight 10
     regular pages - weight 20
     leaf index pages - weight 30
      root index pages 80

This weight would then be factored into the decision to throw pages out
or not.

This project could be independent of the online backup and could have
benfits elsewhere.


View raw message