Adama Science and Technology University

School of Electrical Engineering & Computing

Department of Computer Science and Engineering

Introduction to Distributed
Text Book: Systems
S. Tanenbaum and Maarten Van Steen, Distributed Systems: Principles and Paradigms, 2 nd Ed.

Compiled by: Sufian K.

E-mail: [email protected]
1
 Chapter 6
Consistency & Replication

2
Chapter Outline

 Reasons for Replication

 Replication as Scaling Technique
 Consistency Models
 Consistency Protocols

3
 Reasons for Replication
 Two major reasons: reliability and performance
 Reliability
 If a file is replicated, we can switch to other replicas if
there is a crash on our replica
 we can provide better protection against corrupted
data; similar to mirroring in non-distributed systems
 Performance
 If the system has to scale in size and geographical area
 Place a copy of data in the proximity of process using
them, reducing the time of access and increasing its
performance; for example a Web server is accessed by
thousands of clients from all over the world
 Caching is strongly related to replication; normally by clients

4
 Replication as Scaling Technique
• Replication and caching are widely applied as scaling
techniques

– processes can use local copies and limit access time and
traffic. However, we need to keep the copies consistent;
consistent
but this may

1. Require more network bandwidth

– if the copies are refreshed more often than used (low

access-to-update ratio),
ratio the cost (bandwidth) is more
expensive than the benefits; not all updates have been
used
5
 …Cont’d
2. Itself be subject to serious scalability problems
– Intuitively, a read operation made on any copy should
return the same value (the copies are always the same)
– thus, when an update operation is performed on one
copy, it should be propagated to all copies before a
subsequent operation takes places.
– this is sometimes called tight consistency (a write is
performed at all copies in a single atomic operation or
transaction)
– difficult to implement since it means that all replicas first
need to reach agreement on when exactly an update is
to be performed locally, say by deciding a global ordering
of operations using Lamport timestamps and this takes a
lot of communication time.
6
 …Cont’d

• Replicas must be consistent

– Modifications have to be carried out on all copies

– Problems with network performance

– It is needed to handling concurrency…

 In a distributed system and in the absence of a
global clock and with several copies, it is difficult
to know which is the last write operation.

9
 Consistency Models
 A Consistency Model is a contract between processes
and the data store.

– processes agree to obey certain rules then the data

store promises to work correctly

 In terms of read and write operations on shared data

 Types Consistency Models

1. Data-Centric Consistency Model

2. Client-Centric Consistency Model

10
 …Cont’d
 Data-Centric Consistency Models

– Strict consistency

– Sequential consistency

– Linearizability consistency

– Causal consistency

– FIFO consistency

– Weak consistency

– Release consistency

– Entry consistency

11
 Summary of Data-Centric Consistency
Models
.

Consistency Description
Strict Absolute time ordering of all shared accesses matters.
All processes must see all shared accesses in the same order. Accesses are
Linearizability
furthermore ordered according to a (nonunique) global timestamp
All processes see all shared accesses in the same order.
Sequential
Accesses are not ordered in time
Causal All processes see causally-related shared accesses in the same order.
All processes see writes from each other in the order they were used. Writes from
FIFO
different processes may not always be seen in that order
(a)
Consistency Description
Weak Shared data can be counted on to be consistent only after a synchronization is done
Release Shared data are made consistent when a critical region is exited
Entry Shared data pertaining to a critical region are made consistent when a critical region is
entered.
(b)
a) Consistency models not using synchronization operations.
b) Models with synchronization operations. 18
 …Cont’d

 Client-Centric Consistency Models

– With many applications, updates happen very rarely for

these applications, data-centric models where high
importance is given for updates are not suitable.
– So, very weak consistency is generally sufficient for such
systems.

19
 …Cont’d
 Client-Centric Consistency Models

– Eventual Consistency
 there are many applications where few processes (or a
single process) update the data while many read it and
there are no write-write conflicts;
conflicts we need to handle only
read-write conflicts; e.g., DNS server, Web site
 for such applications, it is even acceptable for readers to
see old versions of the data (e.g., cached versions of a
Web page) until the new version is propagated
 with eventual consistency,
consistency it is only required that updates
are guaranteed to gradually propagate to all replicas.
20
 …Cont’d
 Client-Centric Consistency Models
1. 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.

• Automatically reading your personal calendar updates from different

servers. Monotonic Reads guarantees that the user sees all updates,
no matter from which server the automatic reading takes place.

• Reading (not modifying) incoming mail while you are on the move.
Each time you connect to a different e-mail server, that server fetches
(at least) all the updates from the server you previously visited.

21
 …Cont’d

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

•Updating a program at server S2, and ensuring that all

components on which compilation and linking depends, are also
placed at S2.

•Maintaining versions of replicated files in the correct order

everywhere (propagate the previous version to the server where
the newest version is installed).

22
 …Cont’d

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

•Updating your Web page and guaranteeing that your Web

browser shows the newest version instead of its cached copy.

23
 …Cont’d
4. Writes follow reads:
•Updates are propagated as result of previous read operations.

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

•See reactions to posted articles only if you have the original

posting (a read “pulls in” the corresponding write operation).

24
 Consistency Protocols
1. Primary-based Protocols

– Each data item x in the data store has an associated

primary, which is responsible for coordinating write
operations on x.

2. Replicated Write Protocols

– Write operations can be carried out at multiple replicas

instead of only one.

3. Cache-coherence Protocols

– Controlled by clients instead of servers.

25
 Quiz 1 (5%)

Give short answers

1.What are the reasons for replication? (1 pt.)

2.Through replication, processes can use local copies and

limit access time and traffic. But this may require more
bandwidth and create replica consistency problems. How do
we handle/tackle this problem? (2 pts.)

3.List any 5 Data-centric consistency models. (1 pt.)

4.List the 4 Client-centric consistency models. (1 pt.)

26