Lecture 17 Replication & Consistency Last time: Replication issues? Updating replicas Consistency (how to deal with updated data) (luckily) applications do not always require strict consistency How are updates distributed? Replica management How many replicas? Where to place them?
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Lecture 17Replication & Consistency
Scalability --CONFILCT--- management overheads
Ideally: black box -- complete ‘transparency’ over how data is stored and managed
Management system: Controls the allocated resources and aims to provide transparency
To keep replicas consistent, we generally need to ensure that all conflictingoperations are done in the same order everywhere
Conflicting operations: From the world of transactions:
Problem: 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
Client A: x=1, x=0
Client B: print(x); print(x)
What are the valid sequences printed by B?
Behavior of two processes, operating on the same data item.
A strictly consistent store.
A store that is not strictly consistent.
Any read on a data item X returns a value corresponding to the result of the most recent write on X.
The result of any execution is the same as if
Note: we talk about interleaved execution – there is some total ordering for all operations taken together
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 by different processes.
Causally related relationship:
Concurrent <=> not causally related
A violation of a causally-consistent store.
A correct sequence of events in a causally-consistent store.
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.
Observation:We can actually talk a about a degree of consistency:
Conit: consitency unit specifies the data unit over which consistency is to be enforced.
Conit: contains the variables x and y:
Goal: Show how to avoid system-wide consistency, by concentrating on what each clientswants, instead of what should be maintained by servers.
Idea: If no updates take place for a long enough period time, all replicas will gradually (i.e., eventually) become consistent.
When: Situations where eventual consistency models may make sense
Example: Distributed database to which a user has access through her notebook.
Note: The only thing the user really needs is that the entries updated and/or read at A, are available at B the way she left them in A.