1. More on Replication and Consistency CS-4513, D-Term 20071 More on Replication and Consistency CS-4513 D-Term 2007 (Slides include materials from Operating System Concepts, 7 th ed., by Silbershatz, Galvin, & Gagne, Modern Operating Systems, 2 nd ed., by Tanenbaum, and Distributed Systems: Principles & Paradigms, 2 nd ed. By Tanenbaum and Van Steen)

2. More on Replication and Consistency CS-4513, D-Term 20072 Replication Common in distributed systems –Reliability –Performance Maintaining consistency among replicas –Correctness in operation –Unsurprising behavior Many models for consistency

3. More on Replication and Consistency CS-4513, D-Term 20073 A Mini-Taxonomy of Replication Techniques Copy entire database vs. Update individual items Single source of changes I.e., Primary-based protocols vs. Multiple, independent sources of changes I.e. Replicated-write protocols

4. More on Replication and Consistency CS-4513, D-Term 20074 Copying Entire Database Single source of changes –Simply copy entire database –E.g., DNS domain early implementations, at least …

5. More on Replication and Consistency CS-4513, D-Term 20075 Copying Entire Database (continued) … Multiple concurrent, sources of changes –Every item in database must have timestamp With suitable granularity –Merge copies, item-by-item –Deletions must be preserved At least until all replicas have seen them –Question: can it be proven mathematically that replicas converge?

6. More on Replication and Consistency CS-4513, D-Term 20076 Multiple Sources of Change Example Grapevine Registry In early implementation, an entire registry was copied and merged after each update Each item has timestamp {IP address, local time} Registry’s own timestamp Latest timestamp of any of its members Registry comprises two sublists Current members Deleted members …

7. More on Replication and Consistency CS-4513, D-Term 20077 Grapevine Registry Example (continued) … Merging item-by-item Later version of any item replaces earlier version of same item Item may move between current and deleted lists No provision for resolving inconsistent, concurrent updates by different servers Apply same rule recursively to groups I.e., an item may be a group, comprising other items To update group, merge with copied group by same rule

8. More on Replication and Consistency CS-4513, D-Term 20078 What if Database is Too Big? Propagate updates to individual items Each item has timestamp Newer timestamp replaces older timestamp Each update is a single operation (or sequence) Add, Delete, or Change Apply recursively to groups Propagate only the element that has changed Preserve deletions until all updates have fully propagated

9. More on Replication and Consistency CS-4513, D-Term 20079 Propagating Individual Updates Primary-based protocols Simple, since all updates are monotonically time- stamped Replicated write protocols Similar to merge protocols Later timestamp wins Deletions must be preserved until updates have fully propagated

10. More on Replication and Consistency CS-4513, D-Term 200710 Question What can we say about update order as perceived by clients?

11. More on Replication and Consistency CS-4513, D-Term 200711 Wrap-up — Replication and Consistency Much more to be said Lots of research Practical implementations in a number of large, distributed systems

12. More on Replication and Consistency CS-4513, D-Term 200712 Questions? Next Topic