Scribd
Upload
122 views11 pages

Distributed Database Systems: G Advantages

This document discusses distributed database systems and distributed recovery. It provides information on the advantages and disadvantages of distributed databases. It then discusses various challenges with distributed recovery including dealing with partial failures across sites. It introduces the concept of atomic commitment protocols and their goals in distributed environments. It describes properties these protocols should satisfy and challenges in ensuring atomicity given different types of failures.

Uploaded by

Anonymous jpeHV73mLz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
122 views11 pages

Distributed Database Systems: G Advantages

This document discusses distributed database systems and distributed recovery. It provides information on the advantages and disadvantages of distributed databases. It then discusses various challenges with distributed recovery including dealing with partial failures across sites. It introduces the concept of atomic commitment protocols and their goals in distributed environments. It describes properties these protocols should satisfy and challenges in ensuring atomicity given different types of failures.

Uploaded by

Anonymous jpeHV73mLz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

UVA

DEPARTMENT OF COMPUTER SCIENCE

Distributed Database Systems

Advantages
- autonomy
- resource sharing
- high performance
- high reliability
- flexibility

Disadvantages
increased complexity in
- atomic commitment
- concurrency control
- recovery management

2PC-1

UVA

DEPARTMENT OF COMPUTER SCIENCE

Distributed Recovery

Reliability issues in distributed environments


- major difference from single-node database:
commit/abort of transactions
- processing of logically single operation must
take place in multiple places in distributed DBS

Nature of failure
- all or nothing in a centralized system
- partial operability in distributed systems:
partial failure vs total failure
- partial failures are tricky to deal with since
operational sites are uncertain about the state of
sites either failed or it cannot communicate with
- operational sites may need to be blocked

2PC-2

UVA

DEPARTMENT OF COMPUTER SCIENCE

Atomic Commitment

Transaction commit
- consistent termination of transaction is an issue:
atomic commitment protocols (ACP)
- an important goal of ACP is to minimize the effect
of failures on operational sites ability to continue

Atomic commitment protocol


- all the participating sites must agree: commit/abort
- each casts one of the two votes (yes/no)
and reaches exactly one of the two: commit/abort

2PC-3

UVA

DEPARTMENT OF COMPUTER SCIENCE

Properties of ACP

AC1: consistent termination


- all sites that reach a decision reach the same one

AC2: irrevocable decision


- a site cannot reverse its decision after it is made

AC3: unanimous consent


- everyone must agree before anyone can commit

AC4: exclusion of trivial protocols


- if no failure and all sites vote yes,
decision must be commit
- avoids useless protocol where everyone always
decides to abort

AC5: finite time in decision making


- if failures can be tolerated by ACP, all sites
eventually reach a decision in a finite time

2PC-4

UVA

DEPARTMENT OF COMPUTER SCIENCE

Formal Model of Atomic Commit Protocols

Commit point
- a point reached during the execution of a transaction
at which its fate is determined
"From a certain point onward, there is no longer any
turning back. That is the point that must be reached."
- Kafka

Commit
- unconditional guarantee to execute the transaction
to completion, even in the events of failures

Abort
- unconditional guarantee to back out the transaction
so that none of its effect persist in the database

2PC-5

UVA

DEPARTMENT OF COMPUTER SCIENCE

Atomic Commit Protocols

Irreversible decision
- both commit and abort are irreversible
- if failure occurs before the commit point, then
upon recovery, it must be aborted
- in distributed databases, the task of ACP is
to enforce global atomicity --- unanimity

Why difficult?
- in the absence of failures, unanimous consensus
protocol is rather easy to achieve
- challenge is to find protocols ensuring atomicity
in various types of failure situations

Types of failures
- site (node) failures
- communication link failures

2PC-6

UVA

DEPARTMENT OF COMPUTER SCIENCE

Two-Phase Commit Protocol

Two-phase commit (2PC) protocol


- coordinator and participants
- during the first phase, any participating site
can unilaterally abort the transaction
- by the end of the first phase, all sites has given
up the right to abort the transaction unilaterally
- fundamental weakness: vulnerability to site failures
especially to the failure of the coordinator
- it could result in blocking situations

Blocking
- although it preserves consistency, it is undesirable
- locks cannot be released, making data inaccessible

Window of uncertainty
- period of time during which participants cannot
make unilateral decision

2PC-7

UVA

DEPARTMENT OF COMPUTER SCIENCE

Two-Phase Commit Protocol

Protocol for the coordinator:


Phase 1: send "start transaction" message to all participants
wait for votes from each participant
Phase 2: if all the votes are YES, then send COMMIT to all
participants and commit the transaction
else send ABORT and abort the transaction
Protocol for the participants:
Phase 1: receive "start T" from the coordinator
execute subtransaction and send vote to coordinator
YES to commit
NO to abort
wait for the final decision from coordinator
Phase 2: receive either COMMIT or ABORT and process it

2PC-8

UVA

DEPARTMENT OF COMPUTER SCIENCE

Timeout Actions in 2PC Protocol

In 2PC, a process waits for a message as follows:


1. Coordinator waits for votes from participants
timeout action: abort and send ABORT to participants
2. Participant is waiting for the final decision
timeout action: termination protocol
g

Termination protocol in 2PC


- simple protocol: participant is remained blocked
until it can establish communication with coordinator
- cooperative: participant sends a decision-request
message to other participants
- cooperative protocol could reduce probability of blocking
but cannot eliminate it, and with additional overhead

2PC-8

UVA

DEPARTMENT OF COMPUTER SCIENCE

Independent Recovery in Distributed Databases

Independent recovery
- ability of a recovering process to reach a decision
without communicating with other processes
- very attractive, but not quite feasible
- possible to design an ACP without uncertainty period?
it requires that a process casts its vote and learns
the votes of all others all at once; not possible

Theorem 1:
If communication failures or total failures are
possible, every ACP may cause blocking processes
Theorem 2:
NO ACP can guarantee independent recovery of
failed processes

2PC-10

UVA

DEPARTMENT OF COMPUTER SCIENCE

Evaluation of ACP

Blocking problem of 2PC


A process need to wait for messages before proceeding,
while messages may not arrive due to failures
--- it must take special "time-out" action
- if not in uncertainty period, abort T
- in uncertainty period, it cannot abort unilaterally
--- cooperative termination protocol

Reliability and performance aspects


- resiliency: types of failures it can tolerate
- blocking: can a process blocked?
- time complexity: how long?
- message complexity: how many messages?
- reliability and efficiency are conflicting goals:
each can be achieved at the expense of the other)

2PC-11

You might also like