Principles of Distributed Database

Systems
TS. Phan Thị Hà

© 2020, M.T. Özsu & P. Valduriez TS.

1
Phan Thị Hà
Outline
◼ Introduction
◼ Distributed and parallel database design
◼ Distributed data control
◼ Distributed Transaction Processing
◼ Data Replication
◼ Database Integration – Multidatabase Systems
◼ Parallel Database Systems
◼ Peer-to-Peer Data Management
◼ Big Data Processing
◼ NoSQL, NewSQL and Polystores
◼ Web Data Management
© 2020, M.T. Özsu & P. Valduriez TS.
2
Phan Thị Hà
Outline
◼ Distributed Transaction Processing
❑ Distributed Concurrency Control
❑ Distributed Reliability

© 2020, M.T. Özsu & P. Valduriez TS.

3
Phan Thị Hà
 Transaction

A transaction is a collection of actions that make consistent

transformations of system states while preserving system
consistency.
❑ concurrency transparency
❑ failure transparency

© 2020, M.T. Özsu & P. Valduriez TS.

4
Phan Thị Hà
Transaction Characterization

Begin_transaction
…
Read
Read
…
Write
Read
…
Commit
◼ Read set (RS)
❑ The set of data items that are read by a transaction
◼ Write set (WS)
❑ The set of data items whose values are changed by this transaction
◼ Base set (BS)
❑ RS  WS

© 2020, M.T. Özsu & P. Valduriez TS.

5
Phan Thị Hà
Principles of Transactions

ATOMICITY
❑ all or nothing

CONSISTENCY
❑ no violation of integrity constraints

ISOLATION
❑ concurrent changes invisible  serializable

DURABILITY
❑ committed updates persist

© 2020, M.T. Özsu & P. Valduriez TS.

6
Phan Thị Hà
Transactions Provide…

◼ Atomic and reliable execution in the presence of failures

◼ Correct execution in the presence of multiple user

accesses

◼ Correct management of replicas (if they support it)

© 2020, M.T. Özsu & P. Valduriez TS.

7
Phan Thị Hà
Distributed TM Architecture

© 2020, M.T. Özsu & P. Valduriez TS.

8
Phan Thị Hà
Outline
◼ Distributed Transaction Processing
❑ Distributed Concurrency Control
❑

© 2020, M.T. Özsu & P. Valduriez TS.

9
Phan Thị Hà
Concurrency Control

◼ The problem of synchronizing concurrent transactions

such that the consistency of the database is maintained
while, at the same time, maximum degree of
concurrency is achieved.
◼ Enforce isolation property
◼ Anomalies:
❑ Lost updates
◼ The effects of some transactions are not reflected on the database.
❑ Inconsistent retrievals
◼ A transaction, if it reads the same data item more than once, should
always read the same value.

© 2020, M.T. Özsu & P. Valduriez TS.

10
Phan Thị Hà
Serializability in Distributed DBMS

◼ Two histories have to be considered:

❑ local histories
❑ global history

◼ For global transactions (i.e., global history) to be

serializable, two conditions are necessary:
❑ Each local history should be serializable → local serializability
❑ Two conflicting operations should be in the same relative order
in all of the local histories where they appear together →
global serializability

© 2020, M.T. Özsu & P. Valduriez TS.

11
Phan Thị Hà
 Global Non-serializability

T1: Read(x) T2: Read(x)

x ←x-100 Read(y)
Write(x) Commit
Read(y)
y ←y+100
Write(y)
Commit

◼ x stored at Site 1, y stored at Site 2

◼ LH1, LH2 are individually serializable (in fact serial), but the
two transactions are not globally serializable.
LH1={R1(x),W1(x), R2(x)}
LH2={R2(y), R1(y),W1(y)}
© 2020, M.T. Özsu & P. Valduriez TS.
12
Phan Thị Hà
Concurrency Control Algorithms

◼ Pessimistic
❑ Two-Phase Locking-based (2PL)
◼ Centralized (primary site) 2PL
◼ Primary copy 2PL
◼ Distributed 2PL
❑ Timestamp Ordering (TO)
◼ Basic TO
◼ Multiversion TO
◼ Conservative TO
◼ Optimistic
❑ Locking-based
❑ Timestamp ordering-based

© 2020, M.T. Özsu & P. Valduriez TS.

13
Phan Thị Hà
Locking-Based Algorithms

◼ Transactions indicate their intentions by requesting locks

from the scheduler (called lock manager).
◼ Locks are either read lock (rl) [also called shared lock] or
write lock (wl) [also called exclusive lock]
◼ Read locks and write locks conflict (because Read and
Write operations are incompatible
rl wl
rl yes no
wl no no
◼ Locking works nicely to allow concurrent processing of
transactions.
© 2020, M.T. Özsu & P. Valduriez TS.
14
Phan Thị Hà
 Centralized 2PL

◼ There is only one 2PL scheduler in the distributed system.

◼ Lock requests are issued to the central scheduler.

© 2020, M.T. Özsu & P. Valduriez TS.

15
Phan Thị Hà
Distributed 2PL

◼ 2PL schedulers are placed at each site. Each scheduler

handles lock requests for data at that site.
◼ A transaction may read any of the replicated copies of
item x, by obtaining a read lock on one of the copies of x.
Writing into x requires obtaining write locks for all copies
of x.

© 2020, M.T. Özsu & P. Valduriez TS.

16
Phan Thị Hà
Distributed 2PL Execution

© 2020, M.T. Özsu & P. Valduriez TS.

17
Phan Thị Hà
Deadlock

◼ A transaction is deadlocked if it is blocked and will

remain blocked until there is intervention.
◼ Locking-based CC algorithms may cause deadlocks.
◼ TO-based algorithms that involve waiting may cause
deadlocks.
◼ Wait-for graph
❑ If transaction Ti waits for another transaction Tj to release a lock
on an entity, then Ti → Tj in WFG.

Ti Tj

© 2020, M.T. Özsu & P. Valduriez TS.

18
Phan Thị Hà
Local versus Global WFG

◼ T1 and T2 run at site 1, T3 and T4 run at site 2.

◼ T3 waits for a lock held by T4 which waits for a lock held by T1 which
waits for a lock held by T2 which, in turn, waits for a lock held by T3.

Local WFG

Global WFG

© 2020, M.T. Özsu & P. Valduriez TS.

19
Phan Thị Hà
Deadlock Detection

◼ Transactions are allowed to wait freely.

◼ Wait-for graphs and cycles.
◼ Topologies for deadlock detection algorithms
❑ Centralized
❑ Distributed
❑ Hierarchical

© 2020, M.T. Özsu & P. Valduriez TS.

20
Phan Thị Hà
Centralized Deadlock Detection

◼ One site is designated as the deadlock detector for the

system. Each scheduler periodically sends its local WFG
to the central site which merges them to a global WFG to
determine cycles.
◼ How often to transmit?
❑ Too often ⇒ higher communication cost but lower delays due to
undetected deadlocks
❑ Too late ⇒ higher delays due to deadlocks, but lower
communication cost
◼ Would be a reasonable choice if the concurrency control
algorithm is also centralized.
◼ Proposed for Distributed INGRES
© 2020, M.T. Özsu & P. Valduriez TS.
21
Phan Thị Hà
Hierarchical Deadlock Detection

Build a hierarchy of detectors

© 2020, M.T. Özsu & P. Valduriez TS.

22
Phan Thị Hà
Distributed Deadlock Detection

◼ Sites cooperate in detection of deadlocks.

◼ One example:
❑ Form local WFGs at each modified as follows:
1) Potential deadlock cycles from other sites are
added as edges
2) Join these with regular edges
3) Pass these local WFGs to other sites

❑ Each local deadlock detector:

◼ looks for a cycle that does not involve the external edge. If it exists,
there is a local deadlock which can be handled locally.
◼ looks for a cycle involving the external edge. If it exists, it indicates a
potential global deadlock. Pass on the information to the next site.

© 2020, M.T. Özsu & P. Valduriez TS.

23
Phan Thị Hà
Timestamp Ordering

 Transaction (Ti) is assigned a globally unique timestamp ts(Ti).

 Transaction manager attaches the timestamp to all operations
issued by the transaction.
 Each data item is assigned a write timestamp (wts) and a read
timestamp (rts):
❑ rts(x) = largest timestamp of any read on x
❑ wts(x) = largest timestamp of any read on x
 Conflicting operations are resolved by timestamp order.

Basic T/O:
for Ri(x) for Wi(x)

if ts(Ti) < wts(x) if ts(Ti) < rts(x) and ts(Ti) < wts(x)
then reject Ri(x) then reject Wi(x)
else accept Ri(x) else accept Wi(x)
rts(x)  ts(Ti) wts(x)  ts(Ti)
© 2020, M.T. Özsu & P. Valduriez TS.
24
Phan Thị Hà
Basic Timestamp Ordering

Two conflicting operations Oij of Ti and Okl of Tk → Oij executed before

Okl iff ts(Ti) < ts(Tk).
❑ Ti is called older transaction
❑ Tk is called younger transaction

for Ri(x) for Wi(x)

if ts(Ti) < wts(x) if ts(Ti) < rts(x) and ts(Ti) < wts(x)
then reject Ri(x) then reject Wi(x)
else accept Ri(x) else accept Wi(x)
rts(x)  ts(Ti) wts(x)  ts(Ti)

© 2020, M.T. Özsu & P. Valduriez TS.

25
Phan Thị Hà
Conservative Timestamp Ordering

◼ Basic timestamp ordering tries to execute an operation

as soon as it receives it
❑ progressive
❑ too many restarts since there is no delaying
◼ Conservative timestamping delays each operation until
there is an assurance that it will not be restarted
◼ Assurance?
❑ No other operation with a smaller timestamp can arrive at the
scheduler
❑ Note that the delay may result in the formation of deadlocks

© 2020, M.T. Özsu & P. Valduriez TS.

26
Phan Thị Hà
Multiversion Concurrency Control
(MVCC)

◼ Do not modify the values in the database, create new

values.
◼ Typically timestamp-based implementation
ts(Ti) < ts(xr) < ts(Tj)
◼ Implemented in a number of systems: IBM DB2, Oracle,
SQL Server, SAP HANA, BerkeleyDB, PostgreSQL

© 2020, M.T. Özsu & P. Valduriez TS.

27
Phan Thị Hà
MVCC Reads

◼ A Ri(x) is translated into a read on one version of x.

❑ Find a version of x (say xv) such that ts(xv) is the largest
timestamp less than ts(Ti).

© 2020, M.T. Özsu & P. Valduriez TS.

28
Phan Thị Hà
MVCC Writes

◼ A Wi(x) is translated into Wi(xw) and accepted if the

scheduler has not yet processed any Rj(xr) such that
ts(Ti) < ts(xr) < ts(Tj)

© 2020, M.T. Özsu & P. Valduriez TS.

29
Phan Thị Hà
Optimistic Concurrency Control
Algorithms

Pessimistic execution

Validate Read Compute Write

Optimistic execution

Read Compute Validate Write

© 2020, M.T. Özsu & P. Valduriez TS.

30
Phan Thị Hà
Optimistic Concurrency Control
Algorithms
◼ Transaction execution model: divide into subtransactions
each of which execute at a site
❑ Tij: transaction Ti that executes at site j

◼ Transactions run independently at each site until they

reach the end of their read phases
◼ All subtransactions are assigned a timestamp at the end
of their read phase
◼ Validation test performed during validation phase. If one
fails, all rejected.

© 2020, M.T. Özsu & P. Valduriez TS.

31
Phan Thị Hà
Optimistic CC Validation Test

 If all transactions Tk where ts(Tk) < ts(Tij) have

completed their write phase before Tij has started its
read phase, then validation succeeds
❑ Transaction executions in serial order

© 2020, M.T. Özsu & P. Valduriez TS.

32
Phan Thị Hà
Optimistic CC Validation Test

 If there is any transaction Tk such that ts(Tk)<ts(Tij) and

which completes its write phase while Tij is in its read
phase, then validation succeeds if WS(Tk)  RS(Tij) = Ø
❑ Read and write phases overlap, but Tij does not read data
items written by Tk

© 2020, M.T. Özsu & P. Valduriez TS.

33
Phan Thị Hà
Optimistic CC Validation Test

 If there is any transaction Tk such that ts(Tk)< ts(Tij) and

which completes its read phase before Tij completes its
read phase, then validation succeeds if
WS(Tk)  RS(Tij) = Ø and WS(Tk)  WS(Tij) = Ø
❑ They overlap, but don't access any common data items.

© 2020, M.T. Özsu & P. Valduriez TS.

34
Phan Thị Hà
Snapshot Isolation (SI)

◼ Each transaction “sees” a consistent snapshot of the

database when it starts and R/W this snapshot
◼ Repeatable reads, but not serializable isolation
◼ Read-only transactions proceed without significant
synchronization overhead
◼ Centralized SI-based CC
1) Ti starts, obtains a begin timestamp tsb(Ti)
2) Ti ready to commit, obtains a commit timestamp tsc(Ti) that is greater
than any of the existing tsb or tsc
3) Ti commits if no other Tj such that tsc(Ti) [tsb(Ti), tsc(Ti)]; otherwise
aborted (first committer wins)
4) When Ti commits, changes visible to all Tk where tsb(Tk)> tsc(Ti)

© 2020, M.T. Özsu & P. Valduriez TS.

35
Phan Thị Hà
Distributed CC with SI
◼ Computing a consistent distributed snapshot is hard
◼ Similar rules to serializability
❑ Each local history should be SI
❑ Global history is SI → commitment orders at each site are the same

◼ Dependence relationship: 𝑇𝑖 at site s (𝑇𝑖𝑠 ) is dependent on 𝑇𝑗𝑠

(dependent(𝑇𝑖𝑠 , 𝑇𝑗𝑠 )) iff
(𝑅𝑆(𝑇𝑖𝑠 ) ∩ 𝑊𝑆(𝑇𝑗𝑠 ) ≠ ∅) ∨ (𝑊𝑆 𝑇𝑖𝑠 ∩ 𝑅𝑆(𝑇𝑗𝑠 ) ≠ ∅) ∨ (𝑊𝑆(𝑇𝑖𝑠 ) ∩ 𝑊𝑆(𝑇𝑗𝑠 ) ≠ ∅)
◼ Conditions
1) 𝑑𝑒𝑝𝑒𝑛𝑑𝑒𝑛𝑡(𝑇𝑖 , 𝑇𝑗 ) ∧ 𝑡𝑠𝑏 𝑇𝑖𝑠 < 𝑡𝑠𝑐 𝑇𝑗𝑠 ⟹ 𝑡𝑠𝑏 𝑇𝑖𝑡 < 𝑡𝑠𝑐 𝑇𝑗𝑡 at every site 𝑡 where
𝑇𝑖 and 𝑇𝑗 execute together
2) 𝑑𝑒𝑝𝑒𝑛𝑑𝑒𝑛𝑡(𝑇𝑖 , 𝑇𝑗 ) ∧ 𝑡𝑠𝑐 𝑇𝑖𝑠 < 𝑡𝑠𝑐 𝑇𝑗𝑠 ⟹ 𝑡𝑠𝑐 𝑇𝑖𝑡 < 𝑡𝑠𝑏 𝑇𝑗𝑡 at every site 𝑡 where
𝑇𝑖 and 𝑇𝑗 execute together
3) 𝑡𝑠𝑐 𝑇𝑖𝑠 < 𝑡𝑠𝑐 𝑇𝑗𝑠 ⟹ 𝑡𝑠𝑐 𝑇𝑖𝑡 < 𝑡𝑠𝑏 𝑇𝑗𝑡 at every site 𝑡 where 𝑇𝑖 and 𝑇𝑗 execute
together
© 2020, M.T. Özsu & P. Valduriez TS.
36
Phan Thị Hà
Distributed CC with SI – Executing 𝑇𝑖
Coordinating TM Each site s

Check if first 2
Conditions hold

Positive Yes
Any ?
neg? Update event clock:
No max(own,coord TM)

Update event clock:

Max(event clocks of all s)
Wait

If global commit:
1) Persist 𝑇𝑖 updates
2) Update event clock
© 2020, M.T. Özsu & P. Valduriez TS.
37
Phan Thị Hà
Outline
◼ Distributed Transaction Processing
❑

❑ Distributed Reliability

© 2020, M.T. Özsu & P. Valduriez TS.

38
Phan Thị Hà
Reliability

Problem:
How to maintain

atomicity

durability

properties of transactions

© 2020, M.T. Özsu & P. Valduriez TS.

39
Phan Thị Hà
Ch.10/39
Types of Failures

◼ Transaction failures
❑ Transaction aborts (unilaterally or due to deadlock)
◼ System (site) failures
❑ Failure of processor, main memory, power supply, …
❑ Main memory contents are lost, but secondary storage contents
are safe
❑ Partial vs. total failure
◼ Media failures
❑ Failure of secondary storage devices → stored data is lost
❑ Head crash/controller failure
◼ Communication failures
❑ Lost/undeliverable messages
❑ Network partitioning
© 2020, M.T. Özsu & P. Valduriez TS.
40
Phan Thị Hà
Distributed Reliability Protocols

◼ Commit protocols
❑ How to execute commit command for distributed transactions.
❑ Issue: how to ensure atomicity and durability?
◼ Termination protocols
❑ If a failure occurs, how can the remaining operational sites deal with it.
❑ Non-blocking: the occurrence of failures should not force the sites to
wait until the failure is repaired to terminate the transaction.
◼ Recovery protocols
❑ When a failure occurs, how do the sites where the failure occurred deal
with it.
❑ Independent: a failed site can determine the outcome of a transaction
without having to obtain remote information.
◼ Independent recovery  non-blocking termination

© 2020, M.T. Özsu & P. Valduriez TS.

41
Phan Thị Hà
Two-Phase Commit (2PC)

Phase 1 : The coordinator gets the participants ready to

write the results into the database
Phase 2 : Everybody writes the results into the database
❑ Coordinator :The process at the site where the transaction
originates and which controls the execution
❑ Participant :The process at the other sites that participate in
executing the transaction
Global Commit Rule:
 The coordinator aborts a transaction if and only if at least one
participant votes to abort it.
 The coordinator commits a transaction if and only if all of the
participants vote to commit it.

© 2020, M.T. Özsu & P. Valduriez TS.

42
Phan Thị Hà
State Transitions in 2PC

Coordinator Participant

COMMIT

© 2020, M.T. Özsu & P. Valduriez TS.

43
Phan Thị Hà
Centralized 2PC

© 2020, M.T. Özsu & P. Valduriez TS.

44
Phan Thị Hà
2PC Protocol Actions

© 2020, M.T. Özsu & P. Valduriez TS.

45
Phan Thị Hà
Linear 2PC

V-C: Vote-Commit, V-A: Vote-Abort, G-C: Global-commit, G-A: Global-abort

© 2020, M.T. Özsu & P. Valduriez TS.

46
Phan Thị Hà
Distributed 2PC

© 2020, M.T. Özsu & P. Valduriez TS.

47
Phan Thị Hà
Variations of 2PC

To improve performance by
1) Reduce the number of messages between coordinator &
participants
2) Reduce the number of time logs are written
◼ Presumed Abort 2PC
❑ Participant polls coordinator about transaction’s outcome
❑ No information → abort the transaction
◼ Presumed Commit 2PC
❑ Participant polls coordinator about transaction’s outcome
❑ No information → assume transaction is committed
❑ Not an exact dual of presumed abort 2PC

© 2020, M.T. Özsu & P. Valduriez TS.

48
Phan Thị Hà
Site Failures - 2PC Termination

Coordinator
◼ Timeout in INITIAL
❑ Who cares
◼ Timeout in WAIT
❑ Cannot unilaterally commit
❑ Can unilaterally abort
◼ Timeout in ABORT or COMMIT
❑ Stay blocked and wait for the acks

© 2020, M.T. Özsu & P. Valduriez TS.

49
Phan Thị Hà
 Site Failures - 2PC Termination

Participant
◼ Timeout in INITIAL
❑ Coordinator must have failed
in INITIAL state
❑ Unilaterally abort
◼ Timeout in READY
❑ Stay blocked

© 2020, M.T. Özsu & P. Valduriez TS.

50
Phan Thị Hà
 Site Failures - 2PC Recovery

Coordinator
◼ Failure in INITIAL
❑ Start the commit process upon
recovery
◼ Failure in WAIT
❑ Restart the commit process upon
recovery
◼ Failure in ABORT or COMMIT
❑ Nothing special if all the acks have
been received
❑ Otherwise the termination protocol is
involved

© 2020, M.T. Özsu & P. Valduriez TS.

51
Phan Thị Hà
 Site Failures - 2PC Recovery

Participant
◼ Failure in INITIAL
❑ Unilaterally abort upon recovery
◼ Failure in READY
❑ The coordinator has been
informed about the local decision
❑ Treat as timeout in READY state
and invoke the termination
protocol
◼ Failure in ABORT or COMMIT
❑ Nothing special needs to be done

© 2020, M.T. Özsu & P. Valduriez TS.

52
Phan Thị Hà
2PC Recovery Protocols –
Additional Cases
Arise due to non-atomicity of log and message send
actions
◼ Coordinator site fails after writing “begin_commit” log
and before sending “prepare” command
❑ treat it as a failure in WAIT state; send “prepare” command
◼ Participant site fails after writing “ready” record in log but
before “vote-commit” is sent
❑ treat it as failure in READY state
❑ alternatively, can send “vote-commit” upon recovery
◼ Participant site fails after writing “abort” record in log but
before “vote-abort” is sent
❑ no need to do anything upon recovery
© 2020, M.T. Özsu & P. Valduriez TS.
53
Phan Thị Hà
2PC Recovery Protocols –
Additional Case

◼ Coordinator site fails after logging its final decision

record but before sending its decision to the participants
❑ coordinator treats it as a failure in COMMIT or ABORT state
❑ participants treat it as timeout in the READY state
◼ Participant site fails after writing “abort” or “commit”
record in log but before acknowledgement is sent
❑ participant treats it as failure in COMMIT or ABORT state
❑ coordinator will handle it by timeout in COMMIT or ABORT state

© 2020, M.T. Özsu & P. Valduriez TS.

54
Phan Thị Hà
Problem With 2PC

◼ Blocking
❑ Ready implies that the participant waits for the coordinator
❑ If coordinator fails, site is blocked until recovery
❑ Blocking reduces availability
◼ Independent recovery is not possible
◼ However, it is known that:
❑ Independent recovery protocols exist only for single site failures;
no independent recovery protocol exists which is resilient to
multiple-site failures.
◼ So we search for these protocols – 3PC

© 2020, M.T. Özsu & P. Valduriez TS.

55
Phan Thị Hà
Three-Phase Commit

◼ 3PC is non-blocking.
◼ A commit protocols is non-blocking iff
❑ it is synchronous within one state transition, and
❑ its state transition diagram contains
◼ no state which is “adjacent” to both a commit and an abort state,
and
◼ no non-committable state which is “adjacent” to a commit state
◼ Adjacent: possible to go from one stat to another with a
single state transition
◼ Committable: all sites have voted to commit a
transaction
❑ e.g.: COMMIT state
© 2020, M.T. Özsu & P. Valduriez TS.
56
Phan Thị Hà
State Transitions in 3PC

Coordinator Participant

© 2020, M.T. Özsu & P. Valduriez TS.

57
Phan Thị Hà
3PC Protocol Actions

© 2020, M.T. Özsu & P. Valduriez TS.

58
Phan Thị Hà
Network Partitioning

◼ Simple partitioning
❑ Only two partitions
◼ Multiple partitioning
❑ More than two partitions
◼ Formal bounds:
❑ There exists no non-blocking protocol that is resilient to a
network partition if messages are lost when partition occurs.
❑ There exist non-blocking protocols which are resilient to a single
network partition if all undeliverable messages are returned to
sender.
❑ There exists no non-blocking protocol which is resilient to a
multiple partition.

© 2020, M.T. Özsu & P. Valduriez TS.

59
Phan Thị Hà
Independent Recovery Protocols for
Network Partitioning

◼ No general solution possible

❑ allow one group to terminate while the other is blocked
❑ improve availability
◼ How to determine which group to proceed?
❑ The group with a majority
◼ How does a group know if it has majority?
❑ Centralized
◼ Whichever partitions contains the central site should terminate the
transaction
❑ Voting-based (quorum)

© 2020, M.T. Özsu & P. Valduriez TS.

60
Phan Thị Hà
Quorum Protocols

◼ The network partitioning problem is handled by the

commit protocol.
◼ Every site is assigned a vote Vi.
◼ Total number of votes in the system V
◼ Abort quorum Va, commit quorum Vc
❑ Va + Vc > V where 0 ≤ Va , Vc ≤ V
❑ Before a transaction commits, it must obtain a commit quorum Vc
❑ Before a transaction aborts, it must obtain an abort quorum Va

© 2020, M.T. Özsu & P. Valduriez TS.

61
Phan Thị Hà
Paxos Consensus Protocol

◼ General problem: how to reach an agreement

(consensus) among TMs about the fate of a transaction
❑ 2PC and 3PC are special cases
◼ General idea: If a majority reaches a decision, the global
decision is reached (like voting)
◼ Roles:
❑ Proposer: recommends a decision
❑ Acceptor: decides whether to accept the proposed decision
❑ Learner: discovers the agreed-upon decision by asking or it is
pushed

© 2020, M.T. Özsu & P. Valduriez TS.

62
Phan Thị Hà
Paxos & Complications

◼ Naïve Paxos: one proposer

❑ Operates like a 2PC
◼ Complications
❑ Multiple proposers can exist at the same time; acceptor has to
choose
◼ Attach a ballot number
❑ Multiple proposals may result in split votes with no majority
◼ Run multiple consensus rounds → performance implication
◼ Choose a leader
❑ Some accepts fail after they accept a decision; the remaining
acceptors may not constitute majority
◼ Use ballot numbers

© 2020, M.T. Özsu & P. Valduriez TS.

63
Phan Thị Hà
Basic Paxos – No Failures
Proposer (or Leader) Acceptor
Any
previous
Ack No prop?
Record
Record Ack prepare(bal) Yes

Yes bal > any

Record bal
Ack from prepare(bal) received?
majority?
No

Ignore and
Wait
if all are Ack (not with bal’,val’)
then val ← proposer wants &
nbal ← bal
No
else val ← val’ & nbal ← bal nbal = ack.bal? Ignore

Yes

Record
accepted(nbal,val)

© 2020, M.T. Özsu & P. Valduriez TS.

64
Phan Thị Hà
Basic Paxos with Failures

◼ Some acceptors fail but there is quorum

❑ Not a problem
◼ Enough acceptors fail to eliminate quorum
❑ Run a new ballot
◼ Proposer/leader fails
❑ Choose a new leader and start a new ballot

© 2020, M.T. Özsu & P. Valduriez TS.

65
Phan Thị Hà