In the read one write all protocol (ROWA) [TGGL82], read operations are ex- ecuted by the replica receiving the client requests and write operations must be executed by all replicas. Given the impossibility of executing update operations in the case of a single replica failure, a more flexible protocol, the read one write all available protocol (ROWAA) has been proposed [GSC+83]. The protocol is similar to the ROWA but the definition of the available replicas is dynamic in order to reflect replica failures or network partitions.
In distributed systems, the implementations of the ROWA protocol lead to the definition of several protocols. Their differences reside in the way replicas are contacted in order to execute operations and on the mechanisms used to ensure atomic operation execution.
2.2. REPLICATION PROTOCOLS 13 2.2.1.1 Active Replication
The principle of active replication, also called the state machine approach [Sch93], is that if all replicas start in the same initial state and execute the same operations in the same order, then each of them will do the same work and produce the same output. This principle implies that operations are processed in the same deterministic way.
In the active replication protocol, client operations are send to every replica, get ordered, executed by the replicas and each of the replicas replies to the client after execution. Depending on the failure model assumed, the client considers the operation executed when it receives a certain number of responses from the replicas.
According to the abstract replication protocol the active replication protocol uses the following phases:
1. (RE) The client sends the operations to the replicas using atomic broad- cast [HT93].
2. (SC) During server coordination phase an order to the operations submitted by different clients is established, i.e. the order of the atomic broadcast, and operations are delivered to the replicas.
3. (EX) After delivering operations they are executed by each replica. 4. (END) All replicas send operation results back to the client.
In this protocol there is no need to agreement coordination, as operation execution is deterministic and all replicas execute the same operations in the same order, hence producing the same result.
When considering interactive transactions or transactions involving more than one operation, the request, server coordination and execution phases are executed for every operation until the commit request is issued by the client. It is worth point- ing that transactions could be aborted due to concurrency control constraints, which do not happens in the single operation scenario.
2.2.1.2 Passive Replication
In passive replication or primary-backup replication [BMST93], one of the rep- licas, the primary, plays a special role: all operations requested by clients are directed to it. The primary is also responsible to execute the operations, update the other replicas and respond to the client.
According to the abstract replication protocol the primary-backup replication pro- tocol can be described as:
1. (RE) The client sends the operation to the primary replica. 2. (EX) The primary executes it.
3. (SC) In the server coordination phase, updates produced by the execution are sent to every replica.
4. (AC) In the agreement coordination phase, an atomic commitment protocol is started, so all or none of the replicas apply the updates.
5. (END) After the termination of the atomic commitment protocol the primary sends to the client the result of the operation in case of success or abort oth- erwise.
As all transactions are executed at the primary, it is its responsibility to abort trans- actions due to conflicting operations. If transactions are aborted in the agreement coordination phase, it is never due to conflicting operations but unexpected events, such as disk outage or any other failures, at one or several replicas.
The required adjustments in this protocol to support interactive transaction in- volves a loop with the request and execution phases. When the commit request is received from the client, the protocol enters the server coordination phase and works as in the single operation case.
2.2.1.3 Semi-Active Replication
The semi-active replication protocol [PCD91], is similar to the active replica- tion protocol, allowing for non-deterministic processing. In this protocol, non- deterministic processing is executed only by one of the replicas called the leader which in turn sends the result of the non-deterministic processing to the other replicas called followers. The resulting protocol is thus conceptually similar to state machine protocol except in non-deterministic processing where it resembles a primary-backup protocol.
2.2. REPLICATION PROTOCOLS 15 The protocol can be described using the abstract replication protocol as:
1. (RE) The client sends the operations to the replicas using atomic broadcast. 2. (SC) During server coordination phase operations are ordered according to
the atomic broadcast and delivered to the replicas.
3. (EX) After delivering operations they are executed by each replica, if they only require deterministic processing.
4. (SC) If there are non-deterministic choices to be made, then the leader makes these choices and informs the followers.
5. (END) All replicas send operation results back to the client.
2.2.1.4 Semi-Passive Replication
The semi-passive replication protocol [DSS98], is a replication protocol concep- tually similar to the primary-backup protocol, as only one of the replicas executes the transaction while the others apply its updates.
Contrary to the passive replication protocol, in semi-passive replication client’s operations are sent to all replicas, so replica failures can be made transparent to the client. Every operation is executed only by one of the replicas, selected on a per transaction basis, using the rotating coordinator paradigm [CT96]. This approach distributes transaction processing by all replicas, not overloading the primary as in the primary-backup protocol. After executing a transaction the rep- lica starts a variant of a consensus problem, called Consensus with Deferred Initial
Values. The result of the consensus with deferred initial values execution is the
updates produced by the transaction execution. After terminating this protocol, every replica responds to the client. Using this protocol the client does not have to take care of primary failures. They are handled by the consensus with deferred initially values, which also ensures that the transaction is executed only once. This protocol can be described using the abstract replication protocol as:
1. (RE) The client sends the operations to all replicas.
2. (SC+EX+AC) The server coordination, execution and agreement coordina- tion phases are now merged and considered integrated in the consensus with deferred initial values. For each transaction there is a primary which is se- lected as the coordinator for that round of the consensus. After the selection
of the primary it executes the transaction and proposes its result as the ini- tial value for the consensus problem. The result will be accepted by all the other replicas if it does not fail. In case of primary failure a new primary is selected and the transaction gets executed.
3. (END) After the termination of the consensus problem, all replicas apply the updates to their state and send a response back to the client.
When considering interactive transactions, all transaction operations are executed by the selected replica.