1. Consistency and Replication Chapter 6 Presenter: Yang Jie RTMM Lab Kyung Hee University

2. Data-centric Consistency Models  Data-centric Consistency Models  Strict Consistency  Linearizability and Sequential Consistency  Causal Consistency  FIFO Consistency  Weak Consistency  Release Consistency  Entry Consistency

3. Strict Consistency Behavior of two processes, operating on the same data item. A strictly consistent store. A store that is not strictly consistent.

4. Linearizability and Sequential Consistency A sequentially consistent data store. A data store that is not sequentially consistent.

5. Causal Consistency This sequence is allowed with a casually-consistent store, but not with sequentially or strictly consistent store.

6. FIFO Consistency A valid sequence of events for FIFO consistency

7. Weak Consistency a)A valid sequence of events for weak consistency. b)An invalid sequence for weak consistency.

8. Release Consistency A valid event sequence for release consistency.

9. Entry Consistency A valid event sequence for entry consistency

10. Summary of Consistency Models (1) Consistency models not using synchronization operations. Models with synchronization operations. ConsistencyDescription StrictAbsolute time ordering of all shared accesses matters. Linearizability All processes must see all shared accesses in the same order. Accesses are furthermore ordered according to a (nonunique) global timestamp Sequential All processes see all shared accesses in the same order. Accesses are not ordered in time CausalAll processes see causally-related shared accesses in the same order. FIFO All processes see writes from each other in the order they were used. Writes from different processes may not always be seen in that order (a) ConsistencyDescription WeakShared data can be counted on to be consistent only after a synchronization is done ReleaseShared data are made consistent when a critical region is exited EntryShared data pertaining to a critical region are made consistent when a critical region is entered. (b)

11. Summary of Consistency Models (2) ConsistencyAdvantageDisadvantage StrictIdeal modelRely on absolute global time Linearizability and SequentialEasier and better than strict, time does not play a role. Changing the protocol to improve read performance makes write performance worse. CausalMake a distinction between events potentially causally related and those not. Require keeping track of which processes have seen which writes. FIFOEasy to implement.The results may be counterintuitive. Not all applications require seeing all writes,let alone seeing them in order. Weak(1)Enforces consistency on a group of operations,not on individual reads and writes. (2)Limit only the time when consistency holds,rather than limiting the form of consistency When a synchronization variable is accessed,the data store does not know whether this is being done because the process is either finished writing or is about to start reading data. ReleaseTell the difference between entering a critical region and leaving one. Does not associate shared data items with locks or barriers and at acquire time has to determine empirically which variables it needs. EntryMake sure a process can perform multiple reads and writes in a critical section without invoking any data transport. How to properly associating data with synchronization variables.

12. Summary of 6.3 Client-centric Consistency Models Presented by: Wu Xiaoling Date: 2004-11-23 Real-Time Multimedia Lab Kyung Hee University

13. Client-centric Consistency Models  Eventual Consistency  Monotonic-Read Consistency  Monotonic-Write Consistency  Read-Your-Writes Consistency  Writes-Follow-Reads Consistency

14. Client-centric Consistency Models Environment – “ no ” simultaneous updates – a relatively high degree of inconsistency tolerated Wanted – eventual consistency – consistency seen by one single client

15. Eventual Consistency A mobile user accessing different replicas of a distributed database has problems with eventual consistency

16. Client centric model-Summary Eventual Consistency To solve the problem of eventual consistency: Monotonic read If a process reads the value of a data item x, any successive read operation on x by that process will always return that same value or a more recent value Monotonic write A write operation by a process on a data item x is completed before any successive write operation on x by the same process Read your writes The effect of a write operation by a process on a data item x will always be seen by a successive read operation on x by the same process Writes follow reads A write operation by a process on a data item x following a previous read operation on x by the same process, is garanteed to take place on the same or more recent values of x that was read

17. Xu Hui Real-time and Multimedia LAB Kyung Hee University, Korea Dec. 7, 2004 Distribution and Consistency protocols (Review)

18. Content 1.Distribution Protocols Distributing updates to replicas 2.Consistency Protocols Implementation of consistency models

19. Distribution Protocols  Purpose: Solve the following problem  What is exactly propagated?  Where updates are propagated?  By whom propagation is initiated?  Three Distribution Protocols:  Replica Placement  Update Propagation  Epidemic Protocols

20. Replica Placement  Permanent Replicas  The initial set of replicas  Constitute a distributed data store  Server-Initiated Replicas  Copies of a data store  Created at the initiative of the data store  Exist to enhance performance  Client-Initiated Replicas  Created at the initiative of clients  Commonly known as client caches

21. Replica Placement The logical organization of different kinds of copies of a data store into three concentric rings.

22. Update Propagation Introduction :  Update Propagation generally initiated at a client  Subsequently forwarded to one of the copies Three design issues:  State Vs. Operations  What is actually to be propagated  Pull Vs. Push Protocols  Whether updates are pulled or pushed  Unicasting Vs. Multicasting  Whether unicasting or multicasting should be used

23. Epidemic Protocols Introduction :  Update propagation in eventual-consistent data stores is often implemented by a class of algorithms known as Epidemic Protocols.  Don’t solve any update conflicts  Only concern is propagating updates to all replicas in as few messages as possible. Update Propagation Models (Example: anti-entropy) 1.P only pushes its own updates to Q 2.P only pulls in new updates from Q 3.P and Q send updates to each other

24. Consistency Protocols Introduction:  Consistency protocol  Describe implementations of specific consistency models  Models: sequential consistency, weak consistency with synchronization variables, and atomic consistency  Three Protocols:  Primary-Based Protocols  Remote-Write Protocols & Local-Write Protocols  Replicated-Write Protocols  Active Replication & Quorum-Based Protocols  Cache-coherence Protocols

25. Primary-Based Protocols Primary-based remote-write protocol with a fixed server to which all read and write operations are forwarded. Remote-Write Protocols (1)

26. Primary-Based Protocols The principle of primary-backup protocol. Remote-Write Protocols (2)

27. Primary-Based Protocols Primary-based local-write protocol in which a single copy is migrated between processes. Local-Write Protocols (1)

28. Primary-Based Protocols Primary-backup protocol in which the primary migrates to the process wanting to perform an update. Local-Write Protocols (2)

29. Replicated-Write Protocols The problem of replicated invocations. Active Replication (1)

30. Replicated-Write Protocols a) Forwarding an invocation request from a replicated object. b) Returning a reply to a replicated object. Active Replication (2)

31. Replicated-Write Protocols Quorum-Based Protocols  Basic Idea: require clients to request and acquire the permission(Quorum) of multiple servers before either reading or writing a replicated data item  Scheme:  Suppose: N replicas exist, NR:read quorum, NW:write quorum  Constraints : 1. NR+NW>N 2. NW>N/2 The first constraint is used to prevent read-write conflicts, whereas the second prevents write-write conflicts. Only after the appropriate number of servers has agreed to participate can a file be read or written.