CS 775/875: Fall 2003

1. CS 775/875: Fall 2003 Chapter 14: Replication

2. Why Data Replication? • Performance enhancements • Increased availability • Fault tolerance (related to correctness) • Issue: Replication transparency, consistencey

3. System Model • Asynchronous system • Fail-stop failures only • Unless specified, no network partitioning • Replica managers (servers); static or dynamic; do not crash • Front-end • Five phases: (1) Front-end to RM with a request (ii) RMs coordinate (FIFO, Causal or total ordering) (iii) RMs execute the request (iv) Agreement among RMs (v) RM to Front-end with a response

4. Group Communication • Membership management service---Interface for membership changes, failure detectors, notifying members of any changes in membership, expanding group-ID (for destination) to the list of group members. • View delivery: Views change as members join and leave; a sequence of views are offered to all members; views are received and delivered • Basic requirements of view delivery: Order, integrity, non-triviality • View-synchronous Group Communication: Differs from multicast communication protocols in the sense it also takes into account the group dynamics • Agreement, Integrity, validity • Agreement: Correct processes deliver the same set of messages in any given view. • Integrity: If a process p delivers m, then it will not deliver it again. Message m will only be delivered to members of group g. • Validity (closed groups): Correct processes always deliver the messages that they send. (See Fig. 14.3) • http://www.cdk3.net/ig/slides/Chapter14Slides.pdf

5. Fault-tolerant Services • Linearlizability : “A replicated service is said to be linearizable if for any execution there is some interleaving of the series of operations issued by all the clients that satisfies the following two criteria: • (I) the interleaved sequence of operations meets the specification of a single correct copy of the object • (Ii) the order of operations in the interleaving is consistent with the real times at which the operations occurred in the actual execution • This is operation-wise and not transaction-wise

6. Sequential Consistency • A weaker form of linearlizability. Rules: • (i) The interleaved sequence of operations meets the specification of a single correct copy of the object. • (ii) The order of operations in the interleaving is consistent with the program order in which each individual client executed them. • Every linearizable service is also sequentially consistent. The converse does not hold. • See example in page 567

7. Passive Replication (Primary and backups) • Request, coordination, execution, agreement, response • Satisfies linearizability • A single back-up takes over when the primary fails. • View-synchronous communication among the primary and the backups will help smooth transition. • Used in Sun NIS

8. Active Replication • The FE multicasts client’s request to all replicas • Each replica executes the client’s request and sends a reply • The FE collects the replies and conveys a single reply to the client. • Achieves only sequential consistency • Not linearizability because: the total order in which the replica managers process requests is not necessarily the same real-time order in which the clients made their requests.

9. Highly Available Services • Gossip architecture: Queries (only reads) and updates (no-reads). Guarantees: • (1) each client obtains a consistent service over time. • (2) Relaxed consistency between replicas • It is primarily intended for weaker consistency, but it can be used to achieve sequential consistency • Supports causal ordering • Also supports: Forced (causal and total) ordering and immediate ordering • Immediate ordering: Stronger than forced ordering. It guarantees a consistent order among updates whether the update ordering is specified as causal, forced, or immediate. • Examples: Bulleting board messages (Causal ordering); Adding a new user (forced ordering); deleting a user (immediate ordering)

10. Gossip’s Front-end

11. Gossip’s Replica manager • http://www.cdk3.net/ig/slides/Chapter14Slides.pdf

12. Gossip’s Query operations • http://www.cdk3.net/ig/slides/Chapter14Slides.pdf

13. Update processing • http://www.cdk3.net/ig/slides/Chapter14Slides.pdf

14. Summary of Gossip System • High-availability---works even under partitioning • Lazy approach means not suitable for real-time systems • Scalability---number of gossip messages grows with replicas (2+(R-1)/G) • One solution: let updates be received only by a few replica managers

15. The Coda File System • Similar to AFS: Venus and Vice • In addition, it deals with server failures, portable computers, and scalability • Data is replicated among servers • All available servers are referred to as AVSG (Available server group) • When a file is closed at a client (Venus), the updates are propagated to all replica managers. • When none of the servers are available (AVSG is empty) then the local cache is updated and is used as a server. • When the cache is connected back to servers, proper updating is done. This may sometimes require manual intervention. • Each Venus caches all files needed by a user • Coda Version Vector (CVV) is associated with each file to keep track of the updates. When is there a conflict between two server versions?

16. More on Coda • Update semantics: Open---provides most recent copy from its AVSG; Close---updates sent to all available servers • Accessing replicas • Cache coherence • Disconnected operation

17. Transactions With Replicated Data • One-copy serializability • Two-phase locking for concurrency control • Read-one/write-all • Available copies with validation • Quorum consensus • Virtual partitions • http://www.cdk3.net/ig/slides/Chapter14Slides.pdf

18. Architectures for Replicated Transactions • Primary-copy replication • Two-phase commit protocol • Available copies replication • Network partitions • Quorum consensus • Virtual partitions