Two-phase commit Implications of Two Generals Cannot get agreement - - PowerPoint PPT Presentation

▶
two phase commit implications of two generals
SMART_READER_LITE
LIVE PREVIEW

Two-phase commit Implications of Two Generals Cannot get agreement - - PowerPoint PPT Presentation

Nov 15, 2023 714 likes •1.28k views

Two-phase commit Implications of Two Generals Cannot get agreement in a distributed system to perform some action at the same time. What if we want to update data stored in multiple locations? In a linearizable fashion? Perform group of ops at

slide-1
SLIDE 1

Two-phase commit

slide-2
SLIDE 2

Implications of Two Generals

Cannot get agreement in a distributed system to perform some action at the same time. What if we want to update data stored in multiple locations? In a linearizable fashion? Perform group of ops at logical instant in time, not physical instant

slide-3
SLIDE 3

Setting

Atomic update to data stored in multiple locations Ex: Multikey update to a sharded key-value store Ex: Bank transfer Want:

  • Atomicity: all or none
  • Linearizability: consistent with sequential order
  • No stale reads, no write buffering

For now, let’s ignore availability

slide-4
SLIDE 4

One Phase Commit?

Central coordinator decides, tells everyone else What if some participants can’t do the request?

  • Bank account has zero balance
  • Bank account doesn’t exist, …
slide-5
SLIDE 5

One Phase Commit?

How do we get atomicity/linearizability?

  • Need to apply changes at same logical point in time
  • Need all other changes to appear before/after

Acquire read/write lock on each location

  • If lock is busy, need to wait

For linearizability, need read/write lock on all locations at same time

slide-6
SLIDE 6

Two Phase Commit

Central coordinator asks Participants commit to commit

  • Acquire any locks
  • In the meantime no other ops allowed on that key
  • Delay other concurrent 2PC operations

Central coordinator decides, tells everyone else

  • Release locks
slide-7
SLIDE 7

Calendar event creation

Doug Woos has three advisors (Tom, Zach, Mike) Want to schedule a meeting with all of them

  • Let’s try Tues at 11, people are usually free then

Calendars all live on different nodes! Other students also trying to schedule meetings Nodes can fail, messages can be dropped (of course)

slide-8
SLIDE 8

Calendar event creation (wrong)

Tom Mike Zach Doug

slide-9
SLIDE 9

Calendar event creation (wrong)

Tom Mike Zach Doug Meet at 11 on Tues

slide-10
SLIDE 10

Calendar event creation (wrong)

Tom Mike Zach Doug OK

slide-11
SLIDE 11

Calendar event creation (wrong)

Tom Mike Zach Doug Meeting Doug @ 11 on Tues

slide-12
SLIDE 12

Calendar event creation (wrong)

Tom Mike Zach Doug Meet at 11 on Tues Meeting Doug @ 11 on Tues

slide-13
SLIDE 13

Calendar event creation (wrong)

Tom Mike Zach Doug OK Meeting Doug @ 11 on Tues

slide-14
SLIDE 14

Calendar event creation (wrong)

Tom Mike Zach Doug Meeting Doug @ 11 on Tues Meeting Doug @ 11 on Tues

slide-15
SLIDE 15

Calendar event creation (wrong)

Tom Mike Zach Doug Meet at 11 on Tues Meeting Doug @ 11 on Tues Meeting Doug @ 11 on Tues

slide-16
SLIDE 16

Calendar event creation (wrong)

Tom Mike Zach Doug Busy! Meeting Doug @ 11 on Tues Meeting Doug @ 11 on Tues

slide-17
SLIDE 17

Calendar event creation (wrong)

Tom Mike Zach Doug Meeting Doug @ 11 on Tues Meeting Doug @ 11 on Tues

slide-18
SLIDE 18

Calendar event creation (wrong)

Tom Mike Zach Doug Meeting Doug @ 11 on Tues Meeting Doug @ 11 on Tues

slide-19
SLIDE 19

Calendar event creation (better)

Tom Mike Zach Doug

slide-20
SLIDE 20

Calendar event creation (better)

Tom Mike Zach Doug Meet at 11 on Tues

slide-21
SLIDE 21

Calendar event creation (better)

Tom Mike Zach Doug OK

slide-22
SLIDE 22

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues

slide-23
SLIDE 23

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues Meet at 11 on Tues

slide-24
SLIDE 24

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues OK

slide-25
SLIDE 25

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues Maybe Meeting Doug @ 11 on Tues

slide-26
SLIDE 26

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues Maybe Meeting Doug @ 11 on Tues Meet at 11 on Tues

slide-27
SLIDE 27

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues Maybe Meeting Doug @ 11 on Tues Busy!

slide-28
SLIDE 28

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues Maybe Meeting Doug @ 11 on Tues

slide-29
SLIDE 29

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues Maybe Meeting Doug @ 11 on Tues Never mind!

slide-30
SLIDE 30

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues

slide-31
SLIDE 31

Calendar event creation (better)

Tom Mike Zach Doug Maybe Meeting Doug @ 11 on Tues Never mind!

slide-32
SLIDE 32

Calendar event creation (better)

Tom Mike Zach Doug

slide-33
SLIDE 33

Two-phase commit

Atomic commit protocol (ACP)

  • Every node arrives at the same decision
  • Once a node decides, it never changes
  • Transaction committed only if all nodes vote Yes
  • In normal operation, if all processes vote Yes the

transaction is committed

  • If all failures are eventually repaired, the

transaction is eventually either committed or aborted

slide-34
SLIDE 34

Two-phase commit

Roles:

  • Participants (Mike, Tom, Zach): nodes that must

update data relevant to the transaction

  • Coordinator (Doug): node responsible for executing

the protocol (might also be a participant) Messages:

  • PREPARE: Can you commit this transaction?
  • COMMIT: Commit this transaction
  • ABORT: Abort this transaction
slide-35
SLIDE 35

2PC without failures

Coordinator Participant Participant Prepare Prepare Yes Yes Commit Commit Yes

slide-36
SLIDE 36

2PC without failures

Coordinator Participant Participant Prepare Prepare Yes NO ABORT ABORT Nope

slide-37
SLIDE 37

Failures

In the absence of failures, 2PC is pretty simple! When can interesting failures happen?

  • Participant failures?
  • Coordinator failures?
  • Message drops?
slide-38
SLIDE 38

Participant failures: Before sending response?

Coordinator Participant Participant Prepare Prepare Yes No Abort Abort Decision?

slide-39
SLIDE 39

Participant failures: After sending vote?

Coordinator Participant Participant Prepare Prepare Yes Yes Commit Commit Yes

slide-40
SLIDE 40

Participant failures: Lost vote?

Coordinator Participant Participant Prepare Prepare Yes Yes No Abort Abort Decision?

slide-41
SLIDE 41

Coodinator failures: Before sending prepare

Coordinator Participant Participant Prepare Prepare Yes Yes Yes Commit Commit

slide-42
SLIDE 42

Coordinator failures: After sending prepare

Coordinator Participant Participant Prepare Prepare Yes Yes Yes Commit Commit Prepare Prepare

slide-43
SLIDE 43

Coordinator failures: After receiving votes

Coordinator Participant Participant Prepare Prepare Yes Yes Yes Commit Commit Prepare Prepare Yes Yes

slide-44
SLIDE 44

Coordinator failures: After sending decision

Coordinator Participant Participant Prepare Prepare Yes Commit Yes Yes Commit Decision?

slide-45
SLIDE 45

Do we need the coordinator?

Coordinator Participant Participant Prepare Prepare Yes Commit Commit Yes Yes Decision?

slide-46
SLIDE 46

Can the Participants Decide Amongst Themselves?

Coordinator Participant Participant Prepare Prepare Yes

  • r

No? Commit? Decision? Yes Yes

slide-47
SLIDE 47

Can the Participants Decide Amongst Themselves?

  • Yes, if the participants can know for certain that the

coordinator has failed

  • What if the coordinator is just slow?
  • Participants decide to commit!
  • Coordinator times out, declares abort!
slide-48
SLIDE 48

2PC is a blocking protocol

  • A blocking protocol is one that cannot make

progress if some of the participants are unavailable (either down or partitioned).

  • It has fault-tolerance but not availability.
  • This limitation is fundamental.
slide-49
SLIDE 49

Can We Make 2PC Non-Blocking?

  • Paxos is non-blocking
  • We can use Paxos to update individual keys
  • Can we use Paxos to update multiple keys?
  • If both are on the same shard, easy
  • What if on different shards?
slide-50
SLIDE 50

State machine

Paxos

Lab 4

State machine State machine

Paxos

State machine

Paxos Paxos

Shard master

slide-51
SLIDE 51

State machine

Paxos

Lab 4

State machine State machine

Paxos

State machine

Paxos Paxos

Shard master 2PC 2PC Coordinator

slide-52
SLIDE 52

State machine

Paxos

Lab 4

State machine State machine

Paxos

State machine

Paxos Paxos

Shard master 2PC 2PC Coordinator

slide-53
SLIDE 53

2PC on Paxos

Coordinator Participant Participant Prepare Prepare Yes Yes Commit Commit Yes Paxos Paxos Paxos Paxos Paxos: state machine replication of operation log

slide-54
SLIDE 54

Two Phase Commit on Paxos

Client requests multi-key operation at coordinator Coordinator logs request

  • Paxos: available despite node failures

Coordinator sends prepare Replicas decide to commit/abort, log result

  • Paxos: available despite node failures

Coordinator collects replies, log result

  • Paxos: available despite node failures

Coordinator sends commit/abort Replicas record result

  • Paxos: available despite node failures