- Distributed Updates

Distributed Updates

April 22, 2021

Garcia-Molina/Ullman/Widom: Ch. 17.1-17.5
Atomicity
A transaction is either applied fully (COMMITed) or not at all (ABORTed).
Consistency
Constraints are enforced on the final state of the transaction (and the transaction is ABORTed if they fail).
Isolation
Two transactions running in parallel don't interfere with each other
Durability
Once the database returns from a COMMIT successfully, the data is safe from marmots

How do we uphold these guarantees across multiple databases?

Ground Rules

  • Each node can already enforce these properties locally.
  • All nodes play by the rules (no malicious nodes).
  • Messages either arrive in full or not at all.

Each node has to make local decisions
without global state.

OpenClipart.org
Isolation violation!

Nodes might see operations in a different order.

Idea 1: Route all requests through one node

OpenClipart.org
Pros
Simple
Guaranteed to be Correct
Cons
The node needs to see all transactions.

Idea 2: Have one node define a serial order

Force each node's interactions to obey the order.

OpenClipart.org
Pros
Serving timestamps is fast.
No other bottlenecks.
Cons
When is a transaction committed?
OpenClipart.org

Node 1 commits transaction

Node 2 commits transaction

Client: ???


Node 1 → Client: Commit

Node 2 → Client: Commit


Client sees transaction as committed

Node 1 commits transaction

Node 2 aborts transaction


Node 1 → Client: Commit

Node 2 → Client: Abort


Client sees transaction as aborted?

Atomicity violation!

Node 1 committed the transaction.

Idea 3: Have the client report back

OpenClipart.org
OpenClipart.org

(This is called Two-Phase Commit)

Failure Analysis

What kinds of failures can we tolerate?

  • A message is dropped
  • A node crashes
  • Radioactive marmot attack
OpenClipart.org

Periodically re-send messages

OpenClipart.org

Pre-commit is idempotent

OpenClipart.org

Re-receiving a pre-commit doesn't
change the commit status.

Log commit status in case of repeat requests.

Failure Analysis

What kinds of failures can we tolerate?

  • A message is dropped
  • A node crashes
  • Radioactive marmot attack

Ground Rules

  • Each node can already enforce these properties locally.
  • All nodes play by the rules (no malicious nodes).
  • Messages either arrive in full or not at all.

If the node guarantees Durability,
it will come up in the same state.

Failure = Dropped Message

Failure Analysis

What kinds of failures can we tolerate?

  • A message is dropped
  • A node crashes
  • Radioactive marmot attack
Durability failure

The node never comes back up.

When is the write durable?

Never!

How much durability do you need?

Idea: Replicate data to multiple nodes/sites/planets...

OpenClipart.org
Pros
A backup node exists to come back up when a node blows up.
Cons
Have to wait two message round-trips (or more) to commit.

Idea: Do something like 2-Phase Commit

OpenClipart.org
(Possible) Isolation+Correctness Violation

Some replicas have T1 then T2.
Some have T2 then T1.

Under 2PC, some nodes abort T1 and some abort T2.

Idea: Majority vote

$N$ Replicas

$> \frac{N}{2}$ votes needed for a commit.

When can we consider a replica write successful?

What is a success?

A "successful" read reads the written value.

Can we do better than 2PC?

OpenClipart.org

We need to ensure that Bob sees at least one copy of Alice's write

Pidgeonhole Principle

Alice gets confirmation from $A$ nodes

Bob reads from $B$ nodes

If $A+B > N$ then Bob must read at least one of Alice's writes

Timeouts

What does a node assume when it fails to receive a message?

Assume Node Failure and fail over to replica
All data remains available....
... but if it was only a transient communication failure, there can be inconsistencies
Assume Connection Failure and wait longer
All data remains consistent....
... but unavailable while we wait

Next time

Checkpoint 4