CONSISTENCY AND REPLICATION

1. CONSISTENCY AND REPLICATION

2. DATA-CENTRIC CONSISTENCY MODELS • consistency has been discussed in the context of read and write operations on shared data, available by means of (distributed) shared memory. A (distributed) shared database, or a (distributed) file system.

3. A data store may be physically distributed across multiple machines. • In particular, each process that can access data from the store is assumed to have a local (or nearby) copy available of the entire store. • Write operations are propagated to the other copies

5. Continuous Consistency • There are different ways for applications to specify what inconsistencies they can tolerate. • three independent axes for defining inconsistencies: • deviation in numerical values between replicas, • deviation in staleness between replicas • and deviation with respect to the ordering of update operations. • They refer to these deviations as forming continuous consistency ranges.

6. Numerical deviation can also be understood in terms of the number of updates that have been applied to a given replica, but have not yet been seen by others. • Staleness deviations relate to the last time a replica was updated. • there are classes of applications in which the ordering of updates are allowed to be different at the various replicas, as long as the differences remain bounded.

7. Measuring inconsistency in terms of numerical deviations can be used by applications for which the data have numerical semantics. • One obvious example is the replication of records containing stock market prices. In this case, an application may specify that two copies should not deviate more than $0.02, which would be an absolute numerical deviation. • Alternatively, a relative numerical deviation could be specified, stating that two copies should differ by no more than, for example, 0.5%.

8. Staleness deviations relate to the last time a replica was updated. For some applications, it can be tolerated that a replica provides old data as long as it is not too old. • For example, weather reports typically stay reasonably accurate over some time, say a few hours. • there are classes of applications in which the ordering of updates are allowed to be different at the various replicas, as long as the differences remain bounded. • One way of looking at these updates is that they are applied tentatively to a local copy, awaiting global agreement from all replicas. • As a consequence, some updates may need to be rolled back and applied in a different order before becoming permanent.

9. The Notion of a Conit • A conit specifies the unit over which consistency is to be measured. • For example, in our stock-exchange example, a conit could be defined as a record representing a single stock. • Another example is an individual weather report

11. there is a trade-off between maintaining fine-grained and coarsegrained conits. • If a conit represents a lot of data, such as a complete database, then updates are aggregated for all the data in the conit.

13. Continuous consistency can be implemented as a toolkit which appears to programmers as just another library that they link with their applications. • operations may now also be declared as being dependent on conits: DependsOnConit(ConitQ, 4, 0, 60); read message m from head of queue Q;

14. the call to DependsOnConitO specifies that the numerical deviation, ordering deviation, and staleness should be limited to the values 4, 0, and 60 (seconds), respectively. • This can be interpreted as that there should be at most 4 unseen update operations at other replicas. • there should be no tentative local updates • and the local copy of Q should have been checked for staleness no more than 60 seconds ago.

15. Consistent Ordering of Operations • An important class of models comes from the field of concurrent programming. • Confronted with the fact that in parallel and distributed computing multiple processes will need to share resources and access these resources simultaneously, researchers have sought to express the semantics of concurrent accesses when shared resources are replicated. • sequential consistency and causal consistency models

16. Sequential Consistency • A data store is said to be sequentially consistent when it satisfies the following condition: • 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.

18. Causal Consistency • The causal consistency model represents a weakening of sequential consistency in that it makes a distinction between events that are potentially causally related and those that are not. • In vector timestamps If event b is caused or influenced by an earlier event a, causality requires that everyone else first see a, then see b.

19. 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.

20. Suppose that process P, writes a data item x. Then P2 reads x and writes y. • Here the reading of x and the writing of y are potentially causally related because the computation of y may have depended on the value of x as read by Pz (i.e., the value written by PI)'

21. if two processes spontaneously and simultaneously write two different data items, these are not causally related. • Operations that are not causally related are said to be concurrent • In fig.7.8 the writes Wz(x)b and WI (x)c are concurrent, so it is not required that all processes see them in the same order.

24. Grouping Operations • At the program level read and write operations are bracketed by the pair of operations ENTER_CS and LEAVE_CS where "CS" stands for critical section.

25. Grouping Operations • We now demand that the following criteria are met (Bershad et al., 1993): • 1. An acquire access of a synchronization variable is not allowed to perform with respect to a process until all updates to the guarded shared data have been performed with respect to that process. • 2. Before an exclusive mode access to a synchronization variable by a process is allowed to perform with respect to that process, no other process may hold the synchronization variable, not even in nonexclusive mode. • 3. After an exclusive mode access to a synchronization variable has been performed, any other process' next nonexclusive mode access to that synchronization variable may not be performed until it has performed with respect to that variable's owner.

26. Consistency versus Coherence • A consistency model describes what can be expected with respect to that set when multiple processes concurrently operate on that data. The set is then said to be consistent if it adheres to the rules described by the model. • Where data consistency is concerned with a set of data items, coherence models describe what can be expected to only a single data item

27. CLIENT-CENTRIC CONSISTENCY MODELS • Eventual Consistency • how fast updates should be made available to only reading processes. • Write conflicts-conflicts resulting from two operations that both want to perform an update on the same data • read-write conflicts - in which one process wants to update a data item while another is concurrently attempting to read that item. • They have in common that if no updates take place for a long time, all replicas will gradually become consistent. This form of consistency is called eventual consistency.

28. Data stores that are eventually consistent thus have the property that in the absence of updates, all replicas converge toward identical copies of each other. • Eventual consistency essentially requires only that updates are guaranteed to propagate to all replicas. • Write-write conflicts are often relatively easy to solve when assuming that only a small group of processes can perform updates. • Eventual consistency is therefore often cheap to implement.

30. eventually-consistent data stores and is caused by • the fact that users may sometimes operate on different replicas. • The problem can be alleviated by introducing client-centric consistency. • In essence, client-centric consistency provides guarantees for a single client concerning the consistency of accesses to a data store by that client. No guarantees are given concerning concurrent accesses by different clients.

31. client-centric consistency model ---Monotonic Reads • The first client-centric consistency model is that of monotonic reads. • A data store is said to provide monotonic-read consistency if the following condition holds: ..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.

32. In other words, monotonic-read consistency guarantees that if a process has seen a value of x at time t, it will never see an older version of x at a later time.

34. In Fig. 7-l2(a), process P first performs a read operation on x at L I, returning the value of Xl (at that time). • This value results from the write operations in WS(x I) performed at L I . • Later, P performs a read operation on x at L 2, shown as • R (X2)' To guarantee monotonic-read consistency, all operations in WS(x 1) should have been propagated to L2 before the second read operation takes place. • In other words, we need to know for sure that WS(x I) is part of WS(x 2)' which is expressed as WS(x I ;X2)'

35. client-centric consistency model ---Monotonic Writes • It is important that write operations are propagated in the correct order to all copies of the data store. • This property is expressed in monotonic- write consistency. • In a monotonic-write consistent store, the following condition holds: A write operation by a process on a data item x is completed before any successive write operation on X by the same process.

36. Thus completing a write operation means that the copy on which a successive operation is performed reflects the effect of a previous write operation by the same process, no matter where that operation was initiated. • In other words, a write operation on a copy of item x is performed only if that copy has been brought up to date by means of any preceding write operation, which may have taken place on other copies of x. If need be, the new write must wait for old ones to finish.

38. Monotonic-write consistency is shown in Fig. 7-13. • In Fig. 7-13(a), process P performs a write operation on x at local copy L1, presented as the operation • W(XI). • Later, P performs another write operation on x, but this time at L2, shown as W(X2). • To ensure monotonic-write consistency, it is necessary that the previous write operation at L1 has already been propagated to L2• • This explains operation W(Xl) at L2, and why it takes place before W(X2)

39. client-centric consistency model --- Read Your Writes • A data store is said to provide read-your-writes consistency, if the following condition holds: The effect of a write operation by a process on data item x will always be seen by a successive read operation on x by the same process. • In other words, a write operation is always completed before a successive read operation by the same process, no matter where that read operation takes place

41. In Fig. 7-14(a), process P performed a write operation W(XI) and later a read operation at a different local copy. • Read-your-writes consistency guarantees that the effects of the write operation can be seen by the succeeding read operation. • This is expressed by WS(XI ;X2), which states that W(Xl) is part of WS(X2)' • In contrast, in Fig. 7-14(b), W(Xl) has been left out of WS(X2), meaning that the effects of the previous write operation by process P have not been propagated to L2·

42. client-centric consistency model --- Writes Follow Reads • The last client-centric consistency model is one in which updates are propagated as the result of previous read operations. • A data store is said to provide writes-follow-reads consistency, if the following holds. A write operation by a process on a data item x following a previous read operation on x by the same process is guaranteed to take place on the same or a more recent value of x that was read.

43. In other words, any successive write operation by a process on a data item x will be performed on a copy of x that is up to date with the value most recently read by that process. • Writes-follow-reads consistency can be used to guarantee that users of a network newsgroup see a posting of a reaction to an article only after they have seen the original article

45. This consistency model is shown in Fig. 7-15. In Fig. 7-15(a), a process reads x at local copy L 1. • The write operations that led to the value just read, also appear in the write set at L 2. where the same process later performs a write operation. • In contrast, no guarantees are given that the operation performed at L2, as shown in Fig. 7-15(b), are performed on a copy that is consistent with the one just read at L 1 •

46. CONSISTENCY PROTOCOLS • A consistency protocol describes an implementation of a specific consistency model.

47. 1. Continuous Consistency Bounding Numerical Deviation • If we consider the system at a specific moment in time we will see several submitted writes that still need to be propagated to all servers. • To this end, each server S, will keep track of a log L, of writes that it has performed on its own local copy of x.

48. TW[i,i] represents the aggregated writes submitted to Si' Our goal is for any time t, to let the current value Vi at server S, deviate within bounds from the actual value v (t) of x. This actual value is completely determined by all submitted writes. T hat is. if r (0) is the initial value of x, then

49. when a server S, propagates a write originating from ~ to Sb the latter will be able to learn about the value TW [i,j] at the time the write was sent. In other words, Sk can maintain a view TWk[i,j] of what it believes S, will have as value for TW[i,j].

50. The whole idea is that when server Sk notices that S, has not been keeping in the right pace with the updates that have been submitted to Sb it forwards writes from its log to Si.