Inconsistency caused by: - PowerPoint PPT Presentation

About This Presentation
Title:

Inconsistency caused by:

Description:

Consistent state: Does not execute to completion and any partial effects on database are erased. ... local state transition occurs at a participating. site. ... – PowerPoint PPT presentation

Number of Views:55
Avg rating:3.0/5.0
Slides: 27
Provided by: cjh
Category:

less

Transcript and Presenter's Notes

Title: Inconsistency caused by:


1
  • Inconsistency caused by
  • Concurrently executing transaction.
  • Failures causing partial or incorrect execution
  • of a transaction.

Commit protocols Protocols for directing the
successful execution of a simple
transaction. Termination protocols Protocols at
operational site to commit/abort an unfinished
transaction after a failure.
2
  • Distributed Crash Recovery
  • Centralized Protocols
  • Hierarchical Protocols
  • Linear Protocols
  • Decentralized Protocols
  • Phase
  • Consists of a message round where all
  • Sites exchange messages.
  • Two Phase Commit Protocol
  • ARGUS, LOCUS, INGRES
  • Four Phase Commit Protocol
  • SSD-1
  • Quorum
  • Minimum number of sites needed to
  • proceed with an action

3
Commit/Termination Protocols
  • Two Phase Commit
  • Three Phase Commit
  • Four Phase Commit
  • Linear, Centralized, Hierarchical, Decentralized
    Protocols
  • Two Phase Commit

4
Byzantine General Problem
Two generals are situated on adjacent hills and
enemy is in the valley in between. Enemy can
defeat either general, but not both. To succeed,
both generals must agree to either attack or
retreat. The generals can communicate via
messengers who are subject to capture or getting
lost.
The general may themselves be traitors
or send inconsistent information. Byzantine
Agreement Problem of a set of processors to
agree on a common value for an object. Processors
may fail arbitrarily, die and revive randomly,
send messages when they are not supposed to etc.
5
Figure. The local protocols for the two-phase
commit protocol.
qi
xact noi1 noin
xact yesi1 yesin


wi
ai
send receive
ci
Site i (i 1,2,n)
Figure. The decentralized two-phase commit
protocol.
6
Site 1 (co-ordinator)
Site 2 (back-up)
q1
q2
xact2 act2
request xact2
W1
w2
abort2 act2
commit2 act2
act2 xact3xact4
c2
a2
w1
yes3yes4 commit2
no3no4 abort2
a1
c1
Site i (i 3,4) (slave)
ack2 commit3commit4
ack2 abort3abort4
C1
a1
Figure. The SDD-1 four-phase commit protocol.
7
Protocol
lt Q, ?I, ?0, ?, V, A, C gt
Finite set of states Messages addressed to the
site Messages sent by the site Initial
state Abort states Commit states

Q
Q
Q
Q
V
Q
Q
Properties
1. 2.
V
V
  • Protocols are non-deterministic
  • Sites make local decisions.
  • Messages can arrive in any order.

8
Global State
  • Global state vector containing the states of the
    local protocols.
  • Outstanding messages in the network.

A global state transition occurs whenever a local
state transition occurs at a participating site.
Exactly one global transition occurs for
each local transition.
9
Global state graph
Global state is inconsistent if its state vector
contains both a commit abort state.
10
  • Two states are potentially concurrent if
  • a reachable global state that contains
  • both local states.
  • Concurrency set of s is set of all local states
    that are potentially concurrent with it. C(s)
  • C(w1) V2, a2 , w2
  • The sender set for s,
  • S(s) t/t sends message m m ? M
  • where M be the set of messages that are received
    by s.
  • t is a local state.

11
Global state
  • Inconsistent if it contains both
  • local commit state
  • local abort state
  • Final state if
  • all local states are final

Terminal state if an immediately reachable
successor state ? deadlock
  • Committable state (local) if
  • all sites have voted yes on
  • committing the transaction
  • otherwise, non-committable

12
(No Transcript)
13
Figure. The reachable global state graph for the
protocol of Figure 4.1.
14
Site 1 (co-ordinator)
q1
q2
xact yes
xact no
request xact
yes commit
w1
abort/-
p2
a2
yes abort
p1
a1
c2
failure
c1
time out
Figure. The protocol with failure and timeout
transitions obeying rules 1 2.
15
  • Theorem There exists no protocol using
    independent recovery that is resilient to
    arbitrary failures by two sites.
  • G0 ? abort
  • G1
  • Gk-1 ? site j recovers to abort
  • (only j makes a transition)
  • other sites recover to abort
  • Gk ? site j recovers to commit
  • Gm ? commit
  • Failure of j ? recover to commit
  • Failure of any other site ? recover to abort

Same state exists for other sites
First global state
16
Theorem There exists no protocol resilient to a
network partitioning when messages are lost.
Rule 3 Rule 4
Rule 1 Rule 2
Isomorphic to
undelivered message ? timeout timeout ? failure
Theorem Rules 3 4 are necessary and
sufficient for making protocols resilient to a
partition in a two-site protocol.
Theorem There exists no protocol resilient to a
multiple partition.
17
  • Simple Termination Protocol
  • Message sent by an operational site
  • abort If trans. state is abort
  • (If in abort)
  • committable If trans. state is committable
  • (If in p or c)
  • non-committable If trans. state is neither
    committable nor abort
  • (If in initial or wait)
  • If at least one committable message is
  • received, then commit the transaction,
  • else abort it.
  • Not robust

Site 1 (committable) ? site 2 No message Site 3
(non-committable) ? site 2
Site 2 fails Conclusion Site 3 confused
18
Site 1 Site 2
Site 3
Committable
Noncommittable
Crash Commuts
Site 3 does not know if site 1 was up at
beginning. Does not know it got inconsistent mess
ages
Resilient protocols require at least two
rounds unless no site fails during the execution
of the protocol.
19
Site I (co-ordinator)
Site i (i 2,3,n) (slave)
q1
qi
xacti noi
xacti yesi

w1
aborti

wi
ai
preparei acki
p1
a1
pi
commiti
c1
ci
Figure. The central site three-phase commit
protocol.
20
Figure. Worst case execution of the resilient
transition Protocol.
21
Figure. Summary of the resilient decentralized
termination protocol.
22
Trans. is terminated if abort ? abort all
committable ? commit 2 successive rounds
of ? abort non-committable (no site failure)
23
Commit Rule A transaction is committed at a site
only after the receipt of a round consisting
entirely of committable messages
Termination Rule If a site ever receives two
successive rounds of non-committable messages
and it detects no site failures between
rounds, it can safely abort the transaction.
Lemma Ni(r1) ? Ni(r)
Set of sites sending non-committables to site i
during round r.
Lemma If Ni(r1) Ni(r), then all
messages received by site i during r r 1 were
non-committable messages.
24
Recovery Protocols Protocols at failed site to
complete all Transactions outstanding at the time
of failure
  • Classes of failures
  • Site failure
  • Lost messages
  • Network partitioning
  • Byzantine failures
  • Effects of failures
  • Inconsistent database
  • Transaction processing is blocked.
  • Failed component unavailable.

25
Independent Recovery A recovering site makes a
transition directly to a final state without
communicating with other sites.
Lemma For a protocol, if a local states
concurrency set contains both an abort and
commit, it is not resilient to an arbitrary
failure of a single site.
cannot
si ? commit because other
site may be in abort si ? abort because
other site may be in commit
cannot
Rule 1
  • s Intermediate state
  • If C(s) contains a commit
  • failure transition from
  • s to commit
  • otherwise failure transition from
  • s to abort

26
Rule 2 For each intermediate state si if tj in
s(si) tj has a failure transition to a commit
(abort), then assign a timeout transition from si
to a commit (abort).
Theorem Rules 1 and 2 are sufficient
for designing protocols resilient to a single
site failure.
p consistent p p Failure Timeout
Transition s2 f2 ? f2 ? C(si)
si in s(s2) f2 ? inconsistent
site 1 fails
s1 f1
?
Write a Comment
User Comments (0)
About PowerShow.com