Camera ready version.
This commit is contained in:
parent
20300d40cf
commit
8cea61b148
2 changed files with 39 additions and 22 deletions
|
@ -762,28 +762,42 @@ set of byte ranges with their new values. Note that we still allow
|
|||
code that invokes operations to examine the page file, just not during
|
||||
the redo phase of recovery.
|
||||
|
||||
Recovery works the same way as before, except that it now computes
|
||||
a lower bound for the LSN of each page, rather than reading it from the page.
|
||||
One possible lower bound is the LSN of the most recent checkpoint.
|
||||
Alternatively, \yad could occasionally store its list of dirty pages
|
||||
and their LSNs to the log (Figure~\ref{fig:lsn-estimation}).
|
||||
Recovery works the same way as before, except that it now estimates
|
||||
page LSNs rather than reading them from pages. One safe estimate
|
||||
is the LSN of the most recent archive or log truncation point.
|
||||
Alternatively, \yad could occasionally store its {\em dirty page
|
||||
table} to the log (Figure~\ref{fig:lsn-estimation}). The dirty page
|
||||
table lists all dirty pages and their {\em recovery LSNs}. It
|
||||
provides a lower bound of the LSN of the first log entry that must be
|
||||
applied to each page in the page file. It is used by ARIES to reduce
|
||||
the amount of work that must be performed during REDO.
|
||||
|
||||
Each dirty list is an
|
||||
accurate sparse representation of the LSNs of the entire page file.
|
||||
If a page is present in the most recent list of dirty pages then we use
|
||||
the LSN in the list as our estimate. If the page is not in the list then
|
||||
the page was not updated between the most recent update to the on-disk
|
||||
version (the ``true'' LSN of the page), and the point at which the
|
||||
list was written to log. Therefore, we use the LSN of the log entry that contains the list.
|
||||
The buffer pool must maintain the dirty list whether or not LSN-free
|
||||
pages are in use, so we expect the runtime overhead to be minimal.
|
||||
The recovery LSN (RecLSN) is the LSN of the log entry
|
||||
that caused a clean (up-to-date on disk) page to become dirty. No log
|
||||
entries older than the RecLSN need to be applied to a page during
|
||||
redo. Therefore, redo can safely estimate the page LSN with any number less than RecLSN.
|
||||
If a page is not in the table, redo can use the LSN of the log
|
||||
entry that contains the table, since the page must have been clean
|
||||
when the log entry was produced. \yad writes the dirty page table to
|
||||
log whether or not LSN-free pages are in use, so we expect the runtime
|
||||
overhead to be minimal.
|
||||
|
||||
%Each dirty list is an
|
||||
%accurate sparse representation of the LSNs of the entire page file.
|
||||
%If a page is present in the most recent list of dirty pages then we use
|
||||
%the LSN in the list as our estimate. If the page is not in the list then
|
||||
%the page was not updated between the most recent update to the on-disk
|
||||
%version (the ``true'' LSN of the page), and the point at which the
|
||||
%list was written to log. Therefore, we use the LSN of the log entry that contains the list.
|
||||
%The buffer pool must maintain the dirty list whether or not LSN-free
|
||||
%pages are in use, so we expect the runtime overhead to be minimal.
|
||||
|
||||
\begin{figure}
|
||||
\includegraphics[%
|
||||
viewport=0bp 0bp 460bp 225bp,
|
||||
clip,
|
||||
width=1\columnwidth]{figs/lsn-estimation.pdf}
|
||||
\caption{\label{fig:lsn-estimation}LSN estimation. If a page was not mentioned in the log, it must have been up-to-date on disk.}
|
||||
\caption{\label{fig:lsn-estimation}LSN estimation. If a page was not mentioned in the log, it must have been up-to-date on disk. Here, RecLSN is the LSN of the entry that caused the page to become dirty. Subtracting one yields a safe estimate of the page LSN.}
|
||||
\vspace{-12pt}
|
||||
\end{figure}
|
||||
|
||||
|
@ -1564,17 +1578,20 @@ concurrently with their children~\cite{omtt}.
|
|||
QuickSilver is a distributed transactional operating system. It
|
||||
provides a transactional IPC mechanism, and
|
||||
allows varying degrees of isolation, both to support legacy code, and
|
||||
to implement servers that require special isolation properties.
|
||||
to provide an appropriate environment for custom transactional software~\cite{recoveryInQuickSilver}.
|
||||
By providing an environment that allows multiple,
|
||||
independently written, transactional programs to interoperate, QuickSilver
|
||||
would complement \yad nicely.
|
||||
%It
|
||||
%supports transactions over durable and volatile state, and includes a
|
||||
%number of different commit protocols.
|
||||
Interestingly, its shared logging facility does not
|
||||
hard-code log format or recovery algorithms, and supports a number
|
||||
of interesting optimizations such as distributed
|
||||
logging~\cite{recoveryInQuickSilver}. QuickSilver's logging mechanism
|
||||
is general enough to support \yad.
|
||||
%Interestingly, its shared logging facility does not
|
||||
%hard-code log format or recovery algorithms, and supports a number
|
||||
%of interesting optimizations such as distributed
|
||||
%logging~\cite{recoveryInQuickSilver}. QuickSilver's logging mechanism
|
||||
%is general enough to support \yad.
|
||||
|
||||
The QuickSilver project showed that transactions meet the demands of most
|
||||
The QuickSilver project showed that transactions can meet the demands of most
|
||||
applications, provided that long-running transactions do not exhaust
|
||||
system resources, and that flexible concurrency control policies are
|
||||
available. Nested transactions are
|
||||
|
|
Binary file not shown.
Loading…
Reference in a new issue