Replication Management

1
Replication Management
2
Motivations for Replication

• Performance enhancement
• Increased availability
• Fault tolerance

3
General Requirements

• Replication transparency
• Consistency

4
An Architecture for Replication Management
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
5
Phases of Request Processing

• Issuance unicast or multicast (from the front
  end to replica managers)
• Coordination
• Execution
• Agreement
• Response
• The ordering varies for different systems.

6
Services for Process Groups
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
7
View-Synchronous Group Communications
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
8
Sequential Consistency

• The one-copy semantics of the replicated objects
  is respected.
• The order of operations is preserved for each
  client.

9
The Primary-Backup Model
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
10
Active Replication
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
11
The Gossip Architecture

• A framework for providing high availability of
  service through lazy replication
• A request normally executed at one replica
• Replicas updated by lazy exchange of gossip
  messages (containing most recent updates).

12
Operations in a Gossip Service
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
13
Timestamps

• Each front end keeps a vector timestamp
  reflecting the latest version accessed.
• The timestamp is attached to every request sent
  to a replica.
• Two front ends may exchange messages directly
  these messages also carry timestamps.
• The merging of timestamps is done as usual.

14
Timestamps (contd)

• Each replica keeps a replica timestamp
  representing those updates it has received.
• It also keeps a value timestamp, reflecting the
  updates in the replicated value.
• The replica timestamp is attached to the reply to
  an update, while the value timestamp is attached
  to the reply to a query.

15
Timestamp Propagations
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
16
The Update Log

• Every update, when received by a replica, is
  recorded in the update log of the replica.
• Two reasons for keeping a log
• The update cannot be applied yet it is held
  back.
• It is uncertain if the update has been
  received by all replicas.
• The entries are sorted by timestamps.

17
The Executed Operation Table

• The same update may arrive at a replica from a
  front end and in a gossip message from another
  replica.
• To prevent an update from being applied twice,
  the replica keeps a list of identifiers of the
  updates that have been applied so far.

18
A Gossip Replica Manager
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
19
Processing Query Requests

• A query request q carries a timestamp q.prev,
  reflecting the latest version of the value that
  the front end has seen.
• Request q can be applied (i.e., it is stable) if
  q.prev ? valueTS (the value timestamp of the
  replica that received q).
• Once q is applied, the replica returns the
  current valueTS along with the reply.

20
Processing Update Requests

• For an update u (not a duplicate), replica i
• increments the i-th element of its replica
  timestamp replicaTS by one,
• adds an entry to the log with a timestamp ts
  derived from u.prev by replacing the i-th element
  with that of replicaTS, and
• return ts to the front end immediately.
• When the stability condition u.prev ? valueTS
  holds, update u is applied and u.prev is merged
  with valueTS.

21
Processing Gossip Messages

• For every gossip message received, a replica does
  the following
• Merge the arriving log with its own
  duplicated updates are discarded.
• Apply updates that have become stable.
• A gossip message need not contain the entire log,
  if it is certain that some of the updates have
  been seen by the receiving replica.

22
Updates in Bayou
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
23
About Bayou

• Consistency guarantees
• Merging of updates
• Dependency checks
• Merge procedures

24
Coda vs. AFS

• More general replication
• Greater tolerance toward server crashes
• Allowing disconnected operations

25
Transactions with Replicated Data

• A replicated transactional service should appear
  the same as one without replicated data.
• The effects of transactions performed by various
  clients on replicated data are the same as if
  they had been performed one at a time on single
  data items this property is called one-copy
  serializability.

26
Transactions with Replicated Data (contd)

• Failures should be serialized with respect to
  transactions.
• Any failure observed by a transaction must appear
  to have happened before the transaction started.

27
Schemes for One-Copy Serializability

• Read one/write all
• Available copies replication
• Schemes that also tolerate network partitioning
• available copies with validation
• quorum consensus
• virtual partition

28
Transactions on Replicated Data
Source Instructors guide for G. Coulouris et
al., Distributed Systems Concepts and Design,
Third Edition.
29
Available Copies Replication

• A client's read request on a logical data item
  may be performed by any available replica, but a
  client's update request must be performed by all
  available replicas.
• A local validation procedure is required to
  ensure that any failure or recovery does not
  appear to happen during the progress of a
  transaction.

30
Available Copies Replication (contd)
Source Instructors guide for G. Coulouris et
al., Distributed Systems Concepts and Design,
Third Edition.
31
Network Partition
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
32
Available Copies with Validation

• The available copies algorithm is applied within
  each partition.
• When a partition is repaired, the possibly
  conflicting transactions that took place in the
  separate partitions are validated.
• If the validation fails, some of the transactions
  have to be aborted.

33
Quorum Consensus Methods

• One way to ensure consistency across different
  partitions is to make a rule that operations can
  only be carried out within one of the partitions.
• A quorum is a subgroup of replicas whose size
  gives it the right to execute operations.
• Version numbers or timestamps may be used to
  determine whether copies of the data item are up
  to date.

34
An Example for Quorum Consensus
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
35
Two Network Partitions
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
36
Virtual Partition
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
37
Overlapping Virtual Partitions
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.
38
Creating Virtual Partitions
Source G. Coulouris et al., Distributed Systems
Concepts and Design, Third Edition.