1. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Chapter 7 Consistency And Replication 1. Introduction (what’s it all about) Data-centric consistency Client-centric consistency Replica management Consistency protocols

2. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 7.1 Reasons for Replication Data are replicated to increase the reliability of a system. Replication for performance  Scaling in numbers  Scaling in geographical area  Caveat  Gain in performance  Cost of increased bandwidth for maintaining replication Guaranteeing global ordering on conflicting operations may be a costly operation, downgrading scalability Solution: weaken consistency requirements so that hopefully global synchronization can be avoided

3. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 7.2 Data-centric Consistency Models Figure 7-1. The general organization of a logical data store, physically distributed and replicated across multiple processes. Consistency model: a contract between a (distributed) data store and processes, in which the data store specifies precisely what the results of read and write operations are in the presence of concurrency. Read /Writ e

4. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Continuous Consistency Observation: degree of consistency: replicas may differ in their numerical value replicas may differ in their relative staleness there may differences with respect to (number and order) of performed update operations Conit: consistency unit ⇒ specifies the data unit over which consistency is to be measured.

5. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Continuous Consistency Figure 7-2. An example of keeping track of consistency deviations Each replica maintains a vector clock B sends A operation [ : x := x + 2]; A has made this operation permanent (cannot be rolled back) A has three pending operations ⇒ order deviation = 3 A has missed one operation from B, yielding a max diff of 5 units ⇒ (1,5)

6. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Continuous Consistency Figure 7-3. Choosing the appropriate granularity for a conit. (a) Two updates lead to update propagation. Figure 7-3. Choosing the appropriate granularity for a conit. (b) No update propagation is needed (yet). p.280

7. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Sequential Consistency Figure 7-4. Behavior of two processes operating on the same data item. The horizontal axis is time. A data store is sequentially consistent when: The result of any execution is the same as if the (read and write) operations by all processes on the data store were executed in some sequential order and the operations of each individual process appear in this sequence in the order specified by its program.

8. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Sequential Consistency Figure 7-5. (a) A sequentially consistent data store. (b) A data store that is not sequentially consistent.

9. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Sequential Consistency Figure 7-7. Four valid execution sequences for the processes of Fig. 7-6. The vertical axis is time.

10. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Causal Consistency For a data store to be considered causally consistent, it is necessary that the store obeys the following condition: Writes that are potentially causally related must be seen by all processes in the same order. Concurrent writes may be seen in a different order on different machines. Figure 7-8. causally-consistent store, but not sequentially consistent

11. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Causal Consistency Figure 7-9. (a) A violation of a causally-consistent store. Figure 7-9. (b) A correct sequence of events in a causally- consistent store.

12. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Grouping Operations Necessary criteria for correct synchronization: Accesses to synchronization variable are sequentially consistent No access to a synchronization variable is allowed to be performed until all previous writes have completed everywhere. No data access (group operations) is allowed to be performed until all previous accesses to synchronization variables have been performed. Basic idea: You don’t care that reads and writes of a series of operations are immediately known to other processes. You just want the effect of the series itself to be known.

13. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Grouping Operations Figure 7-10. A valid event sequence for entry consistency. Weak consistency implies that we need to lock and unlock data (implicitly or not). Consistency Model vs. Coherence Model