Lecture 17 replication consistency
Download
1 / 23

Lecture 17 Replication & Consistency - PowerPoint PPT Presentation

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?

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentation

Lecture 17 Replication & Consistency

An Image/Link below is provided (as is) to download presentation

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.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Lecture 17 replication consistency l.jpg

Lecture 17Replication & Consistency


Last time replication issues l.jpg

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?

  • When to get rid of them?

    Redirection/Routing

  • Which replica should clients use?

    Scalability --CONFILCT--- management overheads


Client s view of data store l.jpg

Client‘s view of data-store

Ideally: black box -- complete ‘transparency’ over how data is stored and managed


Management system view on data store l.jpg

Management’ system view on data store

Management system: Controls the allocated resources and aims to provide transparency

  • Consistency model: contract between the data store and the clients

    • the data store specifies precisely what the results of read and write operations are in the presence of concurrency.


Conflicting operations l.jpg

Conflicting operations

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:

  • Read–write conflict: a read operation and a write operation act concurrently

  • Write–write conflict: two concurrent write operations

    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


Types of solutions l.jpg

Types of solutions

  • Data centric: solutions at the data store level

    • Continuous consistency: limit the deviation between replicas, or

    • Constraints on operation ordering at the data-store level

  • Client centric

    • Constraints on operation ordering for each client independently


Data centric consistency l.jpg

Data centric-consistency

  • Solutions based on consistent ordering of operations


Notations for operations on a data store l.jpg

Notations for operations on a Data Store

Notations:

  • Read: Ri(x) a -- client i reads a from location x

  • Write: Wi(x) b -- client i writes b at location x


Example l.jpg

Example

Client A: x=1, x=0

Client B: print(x); print(x)

What are the valid sequences printed by B?

Another example:


Strict consistency l.jpg

Strict Consistency

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.

  • Implicitly assumes the existence of absolute global time.

  • Naturally available in uni-processor systems, but impossible to implement in distributed systems.


Sequential consistency l.jpg

Sequential Consistency

The result of any execution is the same as if

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

    Note: we talk about interleaved execution – there is some total ordering for all operations taken together


Sequential consistency example l.jpg

Sequential Consistency (example)


Causal consistency 1 l.jpg

Causal Consistency (1)

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:

  • A read is causally related to the write that provided the data the read got.

  • A write is causally related to a read that happened before this write in the same process.

  • If write1  read, and read  write2, then write1  write2.

    Concurrent <=> not causally related


Causal consistency example l.jpg

Causal Consistency (Example)

  • This sequence is allowed with a causally-consistent store, but not with sequentially or strictly consistent store.

  • Note: W1(x)a  W2(x)b, but notW2 (x)b  W1(x)c


Causal consistency more examples l.jpg

Causal Consistency (More Examples)

A violation of a causally-consistent store.

A correct sequence of events in a causally-consistent store.


Grouping operations l.jpg

Grouping Operations

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.

  • Accesses to synchronization variables are sequentially consistent.

  • No access to a synchronization variable is allowed to be performed until all previous writes have completed everywhere.

  • No data access is allowed to be performed until all previous accesses to synchronization variables have been performed.


Data centric consistency17 l.jpg

Data centric-consistency

  • Constraints on operation ordering at the data-store level

  • Continuous consistency


Continuous consistency l.jpg

Continuous Consistency

Observation:We can actually talk a about a 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: consitency unit  specifies the data unit over which consistency is to be enforced.


Example19 l.jpg

Example

Conit: contains the variables x and y:

  • Each replica maintains a vector clock

  • B sends A operation [<5,B>: x := x + 2]; A has made this operation permanent(cannot be rolled back)

  • A has three pendingoperations  order deviation = 3

  • A has missed oneoperation from B, yielding a max diff of 5 units  (1,5)


Client centric consistency models l.jpg

Client-centric Consistency Models

  • System model

  • Monotonic reads

  • Monotonic writes

  • Read-your-writes

  • Write-follows-reads

    Goal: Show how to avoid system-wide consistency, by concentrating on what each clientswants, instead of what should be maintained by servers.


Eventual consistency l.jpg

Eventual Consistency

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

  • Mostly read-only workloads

  • No concurrent updates

  • Advantages/Drawbacks


  • Example consistency for mobile users l.jpg

    Example: Consistency for Mobile Users

    Example: Distributed database to which a user has access through her notebook.

    • Notebook acts as a front end to the database.

  • At location A user accesses the database with reads/updates

  • At location B user continues work, but unless it accesses the same server as the one at location A, she may detect inconsistencies:

    • updates at A may not have yet been propagated to B

    • user may be reading newer entries than the ones available at A:

    • user updates at B may eventually conflict with those at A

      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.

  • Idea: the database will appear to be consistent to the user


  • Example basic architecture l.jpg

    Example - Basic Architecture


    ad
  • Login