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 (cont’d) 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 (cont’d) 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: Instructor’s guide for G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. B A Client + front end BBB A A getBalance(A) Client + front end Replica managers deposit(B,3); U T

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 (cont’d) Source: Instructor’s guide for G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. A X Client + front end P B Replica managers deposit(A,3); UT deposit(B,3); getBalance(B) getBalance(A) Replica managers Y M B N A B

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.