6.033 Spring Lecture #18. Distributed transactions Multi-site atomicity Two-phase commit spring 2018 Katrina LaCurts

Transcription

1 6.033 Spring 2018 Lecture #18 Distributed transactions Multi-site atomicity Two-phase 1

2 goal: build reliable systems from unreliable components the abstraction that makes that easier is transactions, which provide atomicity and isolation, while not hindering performance atomicity shadow copies (simple, poor performance) or logs (better performance, a bit more complex) isolation two-phase locking eventually, we also want transaction-based systems to be distributed: to run across multiple machines 2

3 client coordinator A-M server begin A-amount B+amount 3

4 client coordinator A-M server N-Z server begin A-amount Z+amount 4

5 client coordinator A-M server N-Z server begin A-amount Z+amount X problem: one server ted, the other did not 5

6 goal: develop a protocol that can provide multi-site atomicity in the face of all sorts of failures (message loss, message reordering, worker failure, coordinator failure) message failures solved with reliable transport protocol (sequence numbers + ACKs) 6

7 client coordinator A-M server N-Z server assume all parts of the transactions prior to have happened two-phase : nodes agree that they re ready to before ting 7

8 client coordinator A-M server N-Z server timeout; resend X failure: lost 8

9 client coordinator A-M server N-Z server timeout; resend X thanks to sequence numbers, A-M will ACK this message but not re-process it failure: lost ACK for 9

10 client coordinator A-M server N-Z server failure: worker failure while preparing 10

11 client coordinator A-M server! N-Z server abort abort failure: worker failure during 11

12 client coordinator A-M server N-Z server timeout; resend tx? X failure: lost message 12

13 client coordinator A-M server N-Z server timeout; resend X failure: lost ACK for message 13

14 client coordinator A-M server N-Z server failure: worker failure during 14

15 client coordinator A-M server! N-Z server failure: worker failure during 15

16 if workers fail after the point, we cannot abort the transaction. workers must be able to recover into a d state workers write PREPARE records once d. the recovery process reading through the log will indicate which transactions are d but not ted 16

17 client coordinator A-M server! N-Z server failure: worker failure during 17

18 client coordinator A-M server N-Z server tx? failure: worker failure during 18

19 ! client coordinator A-M server N-Z server failure: coordinator failure during 19

20 client coordinator A-M server N-Z server coordinator recovers abort abort failure: coordinator failure during 20

21 client! coordinator A-M server N-Z server failure: coordinator failure during 21

22 client coordinator A-M server N-Z server coordinator recovers failure: coordinator failure during 22

23 problem: in our example, when workers fail, some of the data (e.g., accounts A-M) is completely unavailable 23

24 solution: replicate data but! how will we keep multiple copies of the data consistent? what type of consistency do we want? 24

25 Two-phase allows us to achieve multi-site atomicity: transactions remain atomic even when they require communication with multiple machine. In two-phase, failures prior to the point can be aborted. If workers (or the coordinator) fail after the point, they recover into the d state, and complete the transaction. Our remaining issue deals with availability and replication: we will replicate data across sites to improve availability, but must deal with keeping multiple copies of the data consistent. 25

26 MIT OpenCourseWare Computer System Engineering Spring 2018 For information about citing these materials or our Terms of Use, visit: 26