When the thread creates a new recovery point, it is sufficient to store just the
modified pages, resulting in much smaller recovery points. This approach has also
its drawback. Accessed data are often much smaller than the page size; the recovery
point still contains much unnecessary data.
Such recovery points that are not self-contained but rely on other previously
stored memory points are called incremental recovery points.
Another approach [45] uses programming language extensions to identify shared
data and synchronize access to it. Additional metadata (type, etc.) helps to further
improve the efficiency of that approach.
8.2.3 Message Logging-Based Rollback Recovery
In contrast to the recovery point approach, the message logging rollback recovery is
based on the idea that the execution of a program is deterministic as long as it does
not communicate with other threads or performs I/O. In other words, programs are
therefore assumed to be piecewise deterministic, i.e., programs are deterministic as
long as all determinants; events (internal or external) that affect the programs can be
identified and logged.
RPs of all threads must still be created and stored on stable storage, but messages
and I/O are stored as well. Thus, this approach is particularly suitable for I/O heavy
applications. One can consider the message log-based approach as an extension of
coordinated recovery points where inter-process messages do not trigger the recovery point creation but are stored for later use.
In contrast to the pure recovery point approach, message logging allows the
replay of the program execution after the last recovery line by replaying all stored
messages. The piecewise deterministic assumption must hold also while replaying
the messages, and thus any non-determinism must be avoided. One of the simplest
approaches just stores the number of executed instructions together with the message, which allows, during recovery, the timely correct arrival of the message in the
system, avoiding therefore any non-determinism. A backup computer is used to
store the recovery points as well as the messages and controls the recovery in case
of a failure.
Message logging protocols can be partitioned into three categories: Protocols
with pessimistic logging, optimistic logging, and causal logging. We don’t go into
the depths of these approaches but just give the main idea, advantages, and
drawbacks.
Pessimistic logging requires that the message logging completed before the
message or determinant is delivered to the receiver (synchronous logging), which
leads to a performance impact in the failure-free case, as logging and message
processing cannot be executed in parallel.
The pessimistic approach assumes that failures can occur during message logging but as messages are logged before message delivery, recovery is always
possible to the latest state and cannot lead to orphans, i.e., messages and related
8.2 Overview of Existing Backward Recovery Techniques
119
modified pages, resulting in much smaller recovery points. This approach has also
its drawback. Accessed data are often much smaller than the page size; the recovery
point still contains much unnecessary data.
Such recovery points that are not self-contained but rely on other previously
stored memory points are called incremental recovery points.
Another approach [45] uses programming language extensions to identify shared
data and synchronize access to it. Additional metadata (type, etc.) helps to further
improve the efficiency of that approach.
8.2.3 Message Logging-Based Rollback Recovery
In contrast to the recovery point approach, the message logging rollback recovery is
based on the idea that the execution of a program is deterministic as long as it does
not communicate with other threads or performs I/O. In other words, programs are
therefore assumed to be piecewise deterministic, i.e., programs are deterministic as
long as all determinants; events (internal or external) that affect the programs can be
identified and logged.
RPs of all threads must still be created and stored on stable storage, but messages
and I/O are stored as well. Thus, this approach is particularly suitable for I/O heavy
applications. One can consider the message log-based approach as an extension of
coordinated recovery points where inter-process messages do not trigger the recovery point creation but are stored for later use.
In contrast to the pure recovery point approach, message logging allows the
replay of the program execution after the last recovery line by replaying all stored
messages. The piecewise deterministic assumption must hold also while replaying
the messages, and thus any non-determinism must be avoided. One of the simplest
approaches just stores the number of executed instructions together with the message, which allows, during recovery, the timely correct arrival of the message in the
system, avoiding therefore any non-determinism. A backup computer is used to
store the recovery points as well as the messages and controls the recovery in case
of a failure.
Message logging protocols can be partitioned into three categories: Protocols
with pessimistic logging, optimistic logging, and causal logging. We don’t go into
the depths of these approaches but just give the main idea, advantages, and
drawbacks.
Pessimistic logging requires that the message logging completed before the
message or determinant is delivered to the receiver (synchronous logging), which
leads to a performance impact in the failure-free case, as logging and message
processing cannot be executed in parallel.
The pessimistic approach assumes that failures can occur during message logging but as messages are logged before message delivery, recovery is always
possible to the latest state and cannot lead to orphans, i.e., messages and related
8.2 Overview of Existing Backward Recovery Techniques
119