Combining Concurrency Control and Recovery Instructor: Matei - - PowerPoint PPT Presentation

▶
combining concurrency control and recovery
SMART_READER_LITE
LIVE PREVIEW

Combining Concurrency Control and Recovery Instructor: Matei - - PowerPoint PPT Presentation

Apr 27, 2023 286 likes •841 views

Combining Concurrency Control and Recovery Instructor: Matei Zaharia cs245.stanford.edu Outline What makes a schedule serializable? Conflict serializability Precedence graphs Enforcing serializability via 2-phase locking Shared and

slide-1
SLIDE 1

Combining Concurrency Control and Recovery

Instructor: Matei Zaharia cs245.stanford.edu

slide-2
SLIDE 2

Outline

What makes a schedule serializable? Conflict serializability Precedence graphs Enforcing serializability via 2-phase locking

» Shared and exclusive locks » Lock tables and multi-level locking

Optimistic concurrency with validation Concurrency control + recovery

CS 245 2

slide-3
SLIDE 3

Example: Tj Ti wj(A) ri(A) Commit Ti Abort Tj

Concurrency Control & Recovery

… … … … … …

CS 245 3

Non-persistent commit (bad!)

avoided by recoverable schedules

slide-4
SLIDE 4

Example: Tj Ti wj(A) ri(A) wi(B) Abort Tj [Commit Ti]

… … … … … …

CS 245 4

Concurrency Control & Recovery

Cascading rollback (bad!)

avoided by avoids-cascading

  • rollback (ACR)

schedules

slide-5
SLIDE 5

Core Problem

Schedule is conflict serializable Tj Ti But not recoverable

CS 245 5

slide-6
SLIDE 6

To Resolve This

Need to mark “final” decision for each transaction:

» Commit decision: system guarantees transaction will or has completed, no matter what » Abort decision: system guarantees transaction will or has been rolled back

CS 245 6

slide-7
SLIDE 7

To Model This, 2 New Actions:

ci = transaction Ti commits ai = transaction Ti aborts

CS 245 7

slide-8
SLIDE 8

... ... ... ... Tj Ti wj(A) ri(A) ci ¬ can we commit here?

Back to Example

CS 245 8

slide-9
SLIDE 9

Definition

Ti reads from Tj in S (Tj ÞS Ti) if:

  • 1. wj(A) <S ri(A)
  • 2. aj <S r(A) (<S: does not precede)
  • 3. If wj(A) <S wk(A) <S ri(A) then ak <S ri(A)

CS 245 9

slide-10
SLIDE 10

Definition

Schedule S is recoverable if whenever Tj ÞS Ti and j ¹ i and Ci Î S then Cj <S Ci

CS 245 10

slide-11
SLIDE 11

Notes

In all transactions, reads and writes must precede commits or aborts ó If ci Î Ti, then ri(A) < ai, wi(A) < ai ó If ai Î Ti, then ri(A) < ai, wi(A) < ai Also, just one of ci, ai per transaction

CS 245 11

slide-12
SLIDE 12

How to Achieve Recoverable Schedules?

CS 245 12

slide-13
SLIDE 13

With 2PL, Hold Write Locks Until Commit (“Strict 2PL”)

Tj Ti Wj(A) Cj uj(A) ri(A)

CS 245 13

... ... ... ... ... ...

slide-14
SLIDE 14

With Validation, No Change!

Each transaction’s validation point is its commit point, and only write after

CS 245 14

slide-15
SLIDE 15

Definitions

S is recoverable if each transaction commits

  • nly after all transactions from which it read

have committed. S avoids cascading rollback if each transaction may read only those values written by committed transactions. S is strict if each transaction may read and write only items previously written by committed transactions (≡ strict 2PL).

CS 245 15

slide-16
SLIDE 16

Relationship of Recoverable, ACR & Strict Schedules

Avoids cascading rollback

Recoverable ACR Strict Serial

CS 245 16

slide-17
SLIDE 17

Examples

Recoverable: w1(A) w1(B) w2(A) r2(B) c1 c2 Avoids Cascading Rollback: w1(A) w1(B) w2(A) c1 r2(B) c2 Strict: w1(A) w1(B) c1 w2(A) r2(B) c2

CS 245 17

slide-18
SLIDE 18

Recoverability & Serializability

Every strict schedule is serializable Proof: equivalent to serial schedule based on the order of commit points

» Only read/write from previously committed transactions

CS 245 18

slide-19
SLIDE 19

Recoverability & Serializability

CS 245 19

slide-20
SLIDE 20

Distributed Databases

Instructor: Matei Zaharia cs245.stanford.edu

slide-21
SLIDE 21

Why Distribute Our DB?

Store the same data item on multiple nodes to survive node failures (replication) Divide data items & work across nodes to increase scale, performance (partitioning) Related reasons:

» Maintenance without downtime » Elastic resource use (don’t pay when unused)

CS 245 21

slide-22
SLIDE 22

Outline

Replication strategies Partitioning strategies AC & 2PC CAP Avoiding coordination

CS 245 22

slide-23
SLIDE 23

Outline

Replication strategies Partitioning strategies AC & 2PC CAP Avoiding coordination

CS 245 23

slide-24
SLIDE 24

Replication

General problem:

» How do recover from server failures? » How to handle network failures?

CS 245 24

slide-25
SLIDE 25

CS 245 25

slide-26
SLIDE 26

Replication

Store each data item on multiple nodes! Question: how to read/write to them?

CS 245 26

slide-27
SLIDE 27

Primary-Backup

Elect one node “primary” Store other copies on “backup” Send requests to primary, which then forwards

  • perations or logs to backups

Backup coordination is either:

» Synchronous (write to backups before acking) » Asynchronous (backups slightly stale)

CS 245 27

slide-28
SLIDE 28

Quorum Replication

Read and write to intersecting sets of servers; no one “primary” Common: majority quorum

» More exotic ones exist, like grid quorums

Surprise: primary-backup is a quorum too!

C1: Write C2: Read

CS 245 28

slide-29
SLIDE 29

What If We Don’t Have Intersection?

CS 245 29

slide-30
SLIDE 30

What If We Don’t Have Intersection?

Alternative: “eventual consistency”

» If writes stop, eventually all replicas will contain the same data » Basic idea: asynchronously broadcast all writes to all replicas

When is this acceptable?

CS 245 30

slide-31
SLIDE 31

How Many Replicas?

In general, to survive F fail-stop failures, need F+1 replicas Question: what if replicas fail arbitrarily? Adversarially?

CS 245 31

slide-32
SLIDE 32

What To Do During Failures?

Cannot contact primary?

CS 245 32

slide-33
SLIDE 33

What To Do During Failures?

Cannot contact primary?

» Is the primary failed? » Or can we simply not contact it?

CS 245 33

slide-34
SLIDE 34

What To Do During Failures?

Cannot contact majority?

» Is the majority failed? » Or can we simply not contact it?

CS 245 34

slide-35
SLIDE 35

Solution to Failures:

Traditional DB: page the DBA Distributed computing: use consensus

» Several algorithms: Paxos, Raft » Today: many implementations

  • Zookeeper, etcd, Consul

» Idea: keep a reliable, distributed shared record of who is “primary”

CS 245 35

slide-36
SLIDE 36

Consensus in a Nutshell

Goal: distributed agreement

» e.g., on who is primary

Participants broadcast votes

» If majority of notes ever accept a vote v, then they will eventually choose v » In the event of failures, retry » Randomization greatly helps!

Take CS244B

CS 245 36

slide-37
SLIDE 37

What To Do During Failures?

Cannot contact majority?

» Is the majority failed? » Or can we simply not contact it?

Consensus can provide an answer!

» Although we may need to stall… » (more on that later)

CS 245 37

slide-38
SLIDE 38

Replication Summary

Store each data item on multiple nodes! Question: how to read/write to them?

» Answers: primary-backup, quorums » Use consensus to decide on configuration

CS 245 38

slide-39
SLIDE 39

Outline

Replication strategies Partitioning strategies AC & 2PC CAP Avoiding coordination

CS 245 39

slide-40
SLIDE 40

Partitioning

General problem:

» Databases are big! » What if we don’t want to store the whole database on each server?

CS 245 40

slide-41
SLIDE 41

Partitioning Basics

Split database into chunks called “partitions”

» Typically partition by row » Can also partition by column (rare)

Put one or more partitions per server

CS 245 41

slide-42
SLIDE 42

Partitioning Strategies

Hash keys to servers

» Random assignment

Partition keys by range

» Keys stored contiguously

What if servers fail (or we add servers)?

» Rebalance partitions (use consensus!)

Pros/cons of hash vs range partitioning?

CS 245 42

slide-43
SLIDE 43

What About Distributed Transactions?

Replication:

» Must make sure replicas stay up to date » Need to reliably replicate commit log!

Partitioning:

» Must make sure all partitions commit/abort » Need cross-partition concurrency control!

CS 245 43

slide-44
SLIDE 44

Outline

Replication strategies Partitioning strategies AC & 2PC CAP Avoiding coordination

CS 245 44

slide-45
SLIDE 45

Atomic Commitment

Informally: either all participants commit a transaction, or none do “participants” = partitions involved in a given transaction

CS 245 45

slide-46
SLIDE 46

So, What’s Hard?

CS 245 46

slide-47
SLIDE 47

So, What’s Hard?

All the problems as consensus… …plus, if any node votes to abort, all must decide to abort

» In consensus, simply need agreement on “some” value

CS 245 47

slide-48
SLIDE 48

Two-Phase Commit

Canonical protocol for atomic commitment (developed 1976-1978) Basis for most fancier protocols Widely used in practice Use a transaction coordinator

» Usually client – not always!

CS 245 48

slide-49
SLIDE 49

Two Phase Commit (2PC)

  • 1. Transaction coordinator sends prepare

message to each participating node

  • 2. Each participating node responds to

coordinator with prepared or no

  • 3. If coordinator receives all prepared:

» Broadcast commit

  • 4. If coordinator receives any no:

» Broadcast abort

CS 245 49

slide-50
SLIDE 50

Case 1: Commit

CS 245 50

UW CSE545

slide-51
SLIDE 51

UW CSE545

Case 2: Abort

slide-52
SLIDE 52

2PC + Validation

Participants perform validation upon receipt

  • f prepare message

Validation essentially blocks between prepare and commit message

CS 245 52

slide-53
SLIDE 53

2PC + 2PL

Traditionally: run 2PC at commit time

» i.e., perform locking as usual, then run 2PC when transaction would normally commit

Under strict 2PL, run 2PC before unlocking write locks

CS 245 53

slide-54
SLIDE 54

2PC + Logging

Log records must be flushed to disk on each participant before it replies to prepare

» (And updates must be replicated to F other replicas if doing replication)

CS 245 54