mirror of
https://github.com/janishutz/eth-summaries.git
synced 2026-07-27 21:29:09 +02:00
81 lines
4.8 KiB
TeX
81 lines
4.8 KiB
TeX
\subsection{Recovery}
|
|
Recovery has to make sure that, even in the case of failures, the changes from transactions that have not completed are not visible
|
|
and those of committed transactions are recorded and visible.
|
|
We define undesirable situations and classify histories according to these situations.
|
|
Furthermore, we want to define how histories can avoid such situations.
|
|
|
|
|
|
\subsubsection{Recovery procedures}
|
|
\begin{enumerate}[label=R\arabic*]
|
|
\item Undo all changes from transactions
|
|
\item Redo the changes from committed transactions
|
|
\item Undo the changes that remain in the system from active transactions
|
|
\item Read consistent snapshot from backup, and, if available, apply log
|
|
\end{enumerate}
|
|
R1 is used for abort/rollback of single transactions, R2 and R3 are used on system crash (where we lose the memory, but disks survive)
|
|
and R4 is used for recovery from a system crash with disk loss.
|
|
|
|
This means that we can undo the changes of an active transaction (we keep a copy of the value before it was modified; Shadow pages is a mechanism that would support this),
|
|
we can redo changes made by committed transactions (we keep a persistent record of all the changes made by committed transactions, this why there is a redo log)
|
|
and we have a consistent snapshot to start with (either move forward by taking a snapshot and apply committed transactions,
|
|
or move backward by taking the current state and go back to a consistent state by undoing changes from transactions that should be there).
|
|
|
|
|
|
\subsubsection{Undo - Redo}
|
|
The changes of an aborted transaction are undone typically by restoring the \bi{before image} of the modified value.
|
|
|
|
Changes are redone by restoring the \bi{after image} of the modified value.
|
|
|
|
Databases typically log transactions by keeping before and after images of their changes.
|
|
|
|
|
|
\subsubsection{Recovery on histories}
|
|
\begin{examdetails}
|
|
They like to ask about these, so be sure to understand this properly. Same goes for Conflict Serializability for histories (see \ref{sec:tm-history})
|
|
\end{examdetails}
|
|
A transaction $T_1$ reads from another transaction $T_2$ if $T_1$ reads a value written by $T_2$ at a time when $T_2$ was not aborted.
|
|
|
|
We have:
|
|
\begin{itemize}
|
|
\item \bi{Recoverable} (RC) history: If $T_i$ reads from $T_j$ and commits, then $c_j < c_i$ (same goes for aborts)
|
|
\item \bi{Avoids Cascading Aborts} (ACA) history: If $T_i$ reads $x$ from $T_j$, then $c_j < r_i[x]$
|
|
\item \bi{Strict} (ST) history: If $T_i$ reads from, or overwrites, a value written by $T_j$ then $c_j < o_i[x]$ or $a_j < o_i[x]$, with $o = r$ or $o = w$ ($o$ is an operation)
|
|
\end{itemize}
|
|
|
|
|
|
\paragraph{Recoverable}
|
|
There is no need to undo a committed transaction because it read the wrong data and they commit in their serialization order.
|
|
|
|
Suppose we have the following sequence: $\ldots w_2[x] r_1[x] c_1 \ldots$.
|
|
If $T_2$ aborts, then $T_1$ has read invalid data and since $T_1$ has committed, the data has returned to the user.
|
|
Recovery now involves correcting the application that has processed the data and might have acted upon it, which typically is a very expensive procedure.
|
|
This is avoided by making sure that $T_1$ does not commit until $T_2$ commits and if $T_2$ aborts, then we can safely abort $T_1$,
|
|
since the results have not been returned to the user yet.
|
|
|
|
|
|
\paragraph{ACA}
|
|
Aborting a transaction does not cause aborting others and transactions only read from committed transactions
|
|
|
|
Suppose we have the following sequence: $\ldots w_2[x] r_1[x] a_2 \ldots$.
|
|
When $T_2$ aborts, we have to abort $T_1$ because it has read invalid data (the change made by $T_2$, which will be undone as part of rollback of $T_2$).
|
|
If those cascading aborts happen regularly, the performance will degrade and possibly further transactions will be aborted.
|
|
This is avoided by making sure that uncommitted data is never read (\textit{read committed}).
|
|
|
|
|
|
\paragraph{Strict}
|
|
Undoing a transaction does not undo the changes of other transactions. Transactions further don't read or overwrite updates of uncommitted transactions.
|
|
|
|
Suppose we have the following sequence: $\ldots w_2[x] w_1[x] a_2 \ldots$.
|
|
If we undo $w_2[x]$, we would also remove the changes made by $T_1$. Thus, undoing $T_2$ implies aborting $T_1$.
|
|
Like in ACA, non-strict execution leads to cascading aborts of transactions.
|
|
This is avoided by not letting a value be read or updated unless it is committed.
|
|
|
|
|
|
\paragraph{Why recoverability matters}
|
|
Fixing errors with recovery typically are very expensive:
|
|
\begin{itemize}
|
|
\item Not RC: running my program issues a report, but the data that I got was later removed because a different program aborted $\rightarrow$ report is invalid
|
|
\item Not ACA: Thrashing behaviour when transactions keep aborting each other (my program slows down, or makes no progress at all because of other programs)
|
|
\item Not Strict: recovery after a failure becomes very complex (or impossible)
|
|
\end{itemize}
|