Ιωάννης Κωνσταντίνου.  ACID: Κατοχύρωση ατομικότητας, συνέπειας απομόνωσης και διάρκειας συναλλαγών. ◦ Βασικό σε παραδοσιακές βάσεις δεδομένων ◦ Αντιμετωπίζει.

Παρουσίαση με θέμα: "Ιωάννης Κωνσταντίνου.  ACID: Κατοχύρωση ατομικότητας, συνέπειας απομόνωσης και διάρκειας συναλλαγών. ◦ Βασικό σε παραδοσιακές βάσεις δεδομένων ◦ Αντιμετωπίζει."— Μεταγράφημα παρουσίασης:

1 Ιωάννης Κωνσταντίνου

2  ACID: Κατοχύρωση ατομικότητας, συνέπειας απομόνωσης και διάρκειας συναλλαγών. ◦ Βασικό σε παραδοσιακές βάσεις δεδομένων ◦ Αντιμετωπίζει προβλήματα ταυτόχρονης πρόσβασης στους ίδιους πόρους ◦ Απαιτεί την σειριοποίηση των συναλλαγών ανάλογα με την χρονική στιγμή που δημιουργήθηκαν (πχ πιο πρόσφατες εγγραφές πρέπει να καταχωρηθούν πριν από μεταγενέστερες αναγνώσεις)  Πως εντοπίζουμε πιο γεγονός έγινε πρώτο σε ένα σύνολο από διεργασίες? ◦ Leslie Lamport (Microsoft Research): Logical Clocks και timestamps 2

3  Οι ACID απαιτήσεις είναι ακριβές σε ένα client/server σύστημα, πόσο μάλλον σε ένα κατανεμημένο σύστημα.  Eventual Consistency: Ανάγκη για χαλάρωση των ACID σε κατανεμημένες βάσεις. ◦ Εφαρμογές που δεν απαιτούν όλοι οι πελάτες να έχουν άμεση πρόσβαση στην νεότερη έκδοση ενός αντικειμένου (facebook status updates).  Τι γίνεται σε περίπτωση που θέλουμε περισσότερες εγγυήσεις? ◦ Leslie Lamport: Ο κατανεμημένος αλγόριθμος συναίνεσης (consensus) PAXOS 3

4  Time, Clocks and the Ordering of Events in a Distributed System  The PAXOS protocol 4

5  Δυο γεγονότα δεν είναι πάντα χρονικά ταξινομημένα σε ένα κατανεμημένο σύστημα.  Μόνο η σειρά γεγονότων που έχουν σχέση αιτίας/αποτελέσματος έχει σημασία.  Εμπνευσμένο από την ειδική θεωρία της σχετικότητας του A. Einstein.  Υλοποίηση με λογικά ρολόγια (logical clocks) 5

6 Αντιστοίχηση ακολουθίας αριθμών σε μηνύματα ◦ Όλες οι συμμετέχοντες διεργασίες μπορούν να συμφωνήσουν σε μια σειρά με την οποία έγιναν τα γεγονότα ◦ Αντίθετα με τα φυσικά ρολόγια (physical clocks): συγκεκριμένη ώρα Δεν θεωρούμε μια κεντρική αρχή που λέει την ώρα ◦ Το κάθε σύστημα/διεργασία έχει το δικό του ρολόι. ◦ Όχι συνολική ταξινόμηση γεγονότων  Δεν υπάρχει η έννοια του “πότε έγινε” κάτι αλλά, “ποιο από τα δύο έγινε πρώτο”?

7 Ένα λογικό ρολόι είναι ένας μηχανισμός για τη καταγραφή χρονολογικών σχέσεων και σχέσεων που έχουν σχέση αιτίας/αποτελέσματος Υλοποίηση ενός ρολογιού – Δομή δεδομένων – Πρωτόκολλο ενημέρωσης ρολογιού Σημαντικοί αλγόριθμοι λογικών ρολογιών είναι αυτοί που βασίζονται σε – Μονοδιάστατα ρολόγια – Διανυσματικά ρολόγια

8 Εισαγωγή της έννοιας του λογικού χρόνου αντί για τον απόλυτο χρόνο Μερική διάταξη των γεγονότων σε σχέση με την σειρά εμφάνισης – Causally Related Events Εάν το γεγονός Α έγινε πριν από το γεγονός Β, τότε το Α επηρεάζει το Β. – Ταυτόχρονα γεγονότα Δυο διαφορετικά γεγονότα Α και Β είναι ταυτόχρονα (concurrent) εάν το Α δεν έγινε πριν το Β και το Β δεν έγινε πριν το Α. Δηλαδή τα γεγονότα δεν συνδέονται με κάποια σχέση αιτίας/αποτελέσματος. Επέκταση της σχέσης “Happens Before” για μια συνεπή ολική διάταξη στον χρόνο σε ένα κατανεμημένο σύστημα. Παράδειγμα: make utility – χρόνοι δημιουργίας του input.c and input.o

9  Ο Lamport παρουσίασε ένα σύστημα λογικών ρολογιών με σκοπό τον σωστό ορισμό της σχέσης “happened before”  Η κάθε διεργασία P έχει το δικό της ρολόι C.  Για κάθε γεγονός ‘a’ σε μια διεργασία, το C μπορεί να θεωρηθεί μια συνάρτηση που θέτει έναν αριθμό C(a) ο οποίος είναι μια χρονοσφραγίδα (timestamp) του γεγονότος ‘a’ στην διεργασία P. Οι αριθμοί αυτοί δεν έχουν καμία σχέση με τον φυσικό χρόνο – για αυτό λέγονται λογικά ρολόγια.

10 Εάν το ‘a’ και ‘b’ είναι δυο γεγονότα της ίδιας διεργασίας, και το ‘a’ έγινε πριν το ‘b’ τότε ισχύει a -> b. Εάν το ‘a’ είναι το αποτέλεσμα της αποστολής ενός μηνύματος από μια διεργασία και ‘b’ είναι το αποτέλεσμα της λήψης του μηνύματος από μια άλλη διεργασία τότε a -> b. Εάν a -> b και b -> c, ισχύει a -> c. Εάν a (not) -> b και b (not) -> a, τότε τα a και b είναι concurrent (ταυτόχρονα). Eάν τα a και b συμβούν σε διαφορετικές διεργασίες που δεν ανταλλάσουν μηνύματα, τότε ούτε a -> b ούτε b -> a

11

12  Πως πετυχαίνουμε ένα συνεπές σετ από λογικά ρολόγια, ένα για κάθε διαδικασία? 

13

14

15

16 E1/E2 είναι sending/receipt του ίδιου μηνύματος, τότε“E1 -> E2”, πχ A2 -> B4. “E1 -> E2 and E2 -> E3” then “E1 -> E3”, πχ. A1 → B4. Ταυτόχρονα: A2 και B3, B4 και C2.

17  3 συστήματα: P 0, P 1, P 2  Γεγονότα a, b, c, …  Τοπικός μετρητής γεγονότων σε κάθε σύστημα  Περιστασιακά τα συστήματα επικοινωνούν

18 ab hi k P1P1 P2P2 P3P3 12 13 21 df g 3 c 2 4 6 e 5 j

19 ab i k j P1P1 P2P2 P3P3 12 13 21 df g 3 c 2 4 6 Λάθος σειρά: e  h f  k h e 5

20 ab i k j P1P1 P2P2 P3P3 12 17 21 df g 3 c 2 4 6 6 7 h e 5

21  Ο αλγόριθμος χρειάζεται έναν μονότονα αυξανόμενο counter  Αύξηση του counter τουλάχιστον κάθε φορά που χρειάζεται μια χρονοσφραγίδα  Κάθε γεγονός έχει μια χρονοσφραγίδα Lamport  Για 2 γεγονότα a  b ισχύει: L(a) < L(b)

22 a  b, b  c, …:Τα τοπικά γεγονότα μπαίνουν σε σειρά i  c, f  d, d  g, … :Ο Lamport βάζει σε σειρά send  receive γεγονότα Ταυτόχρονα γεγονότα (πχ, a & j) μπορεί να έχουν την ίδια χρονοσφραγίδα … ή όχι ab hi k j P1P1 P2P2 P3P3 12 17 71 df g 3 c 6 4 6 e 5

23

24 Μπορούμε να θέσουμε κάθε χρονοσφραγίδα να είναι μοναδική ◦ Έστω καθολική λογική χρονοσφραγίδα (T i, i)  Το T i είναι μια τοπική χρονοσφραγίδα  Το i δείχνει το id της διεργασίας (καθολικά μοναδικό)  Πχ(διεύθυνση IP, ID διεργασίας) ◦ Σύγκριση χρονοσφραγίδων: (T i, i) < (T j, j) Εάν και μόνο εάν T i < T j ή T i = T j και i < j Αυθαίρετη ταξινόμηση των διεργασιών.

25 ab i k j P1P1 P2P2 P3P3 1.12.1 1.27.2 7.31.3 df g 3.1 c 6.2 4.1 6.1 h e 5.1

26  Updating a replicated database and leaving it in an inconsistent state.

27

28  Υπέρ  Παίρνουμε μια ολική ταξινόμηση των γεγονότων στο σύστημα, χρησιμοποιώντας μόνο την σχέση αιτίας/αποτελέσματος.  Χρειάζεται μόνο ένας integer ανά διεργασία.  Κατά  Clocks are not strongly consistent: clocks lose track of the timestamp of the event on which they are dependent on. This is because we are using a single integer to store the local and logical time.

29  Causality ◦ If a->b then event a can affect event b  Concurrency ◦ If neither a->b nor b->a then one event cannot affect the other  Partial Ordering ◦ Causal events are sequenced  Total Ordering ◦ All events are sequenced  Υπέρ : Παίρνουμε μια ολική ταξινόμηση των γεγονότων στο σύστημα, χρησιμοποιώντας μόνο την σχέση αιτίας/αποτελέσματος. Μόνο ένας int ανά process

30  Ένας αλγόριθμος ομοφωνίας consensus ◦ Από τους πιο αποτελεσματικούς και κομψούς αλγόριθμους ομοφωνίας ◦ Στα κατανεμημένα συστήματα χρησιμοποιείται κατά κόρον

31  Developed by Leslie Lamport (from the Lamport clock)  “A fault-tolerant file system called Echo was built at SRC in the late 80s. The builders claimed that it would maintain consistency despite any number of non-Byzantine faults, and would make progress if any majority of the processors were working.”  “I decided that what they were trying to do was impossible, and set out to prove it. Instead, I discovered the Paxos algorithm.”  “I decided to cast the algorithm in terms of a parliament on an ancient Greek island (Paxos).”

32  The paper abstract: ◦ “Recent archaeological discoveries on the island of Paxos reveal that the parliament functioned despite the peripatetic propensity of its part-time legislators. The legislators maintained consistent copies of the parliamentary record, despite their frequent forays from the chamber and the forgetfulness of their messengers. The Paxon parliament’s protocol provides a new way of implementing the state-machine approach to the design of distributed systems.”

33  Ο κόσμος πίστευε ότι το Paxos ήταν αστείο.  Ο Lamport τελικά δημοσίευσε το άρθρο 8 χρόνια αργότερα το 1998 αφού γράφτηκε 1990. ◦ Τίτλος: “The Part-Time Parliament”  Το αρχικό paper ήταν δυσνόητο.  Ο Lamport έγραψε μια πιο κατανοητή έκδοση. ◦ Τίτλος: “Paxos Made Simple” ◦ Περίληψη: “The Paxos algorithm, when presented in plain English, is very simple.”

34  Γενικά πως συμφωνεί ο κόσμος σε κάτι? ◦ Ερώτηση: Πρέπει ο Γιάννης να βάλει 10 σε όλους όσους παρακολουθούν το μάθημα Λειτουργικά συστήματα ΙΙ? ◦ Είσοδος: Όλοι λένε Ναι/Όχι. ◦ Έξοδος: μια συμφωνία σε Ναι ή Όχι.  Πολλά προβλήματα κατανεμημένων συστημάτων μπορούν να αναχθούν σε ένα πρόβλημα ομοφωνίας ◦ Mutual exclusion, leader election, total ordering, etc.  Paxos ◦ Πως γίνεται πολλαπλές διεργασίες να συμφωνήσουν σε μια τιμή? ◦ Κάτω από αστοχίες υλικού, κατατμήσεις δικτύου, καθυστερήσεις μηνυμάτων, κλπ?

35  Πολύ σημαντικό πρόβλημα!  Αρκετά πραγματικά συστήματα υλοποιούν το Paxos ◦ Google Chubby, Apache Zookeeper ◦ MS Bing cluster management ◦ Etc.  Amazon CTO Werner Vogels (ο eventually consistent κύριος στο blog του “Job Openings in My Group”) ◦ “What kind of things am I looking for in you?” ◦ “You know your distributed systems theory: You know about logical time, snapshots, stability, message ordering, but also acid and multi-level transactions. You have heard about the FLP impossibility argument. You know why failure detectors can solve it (but you do not have to remember which one diamond-w was). You have at least once tried to understand Paxos by reading the original paper.”

36  Το δίκτυο είναι ασύγχρονο με δικτυακές καθυστερήσεις.  Το δίκτυο μπορεί χάσει ή να αντιγράψει μηνύματα (αλλά δεν τα αλλάζει επίτηδες)  Οι διεργασίες μπορούν να κρασάρουν και να ανανήψουν  Οι διεργασίες είναι non-Byzantine.  Οι διεργασίες έχουν μόνιμο αποθηκευτικό χώρο.  Οι διεργασίες μπορούν να προτείνουν τιμές.  Στόχος: κάθε διεργασία συμφωνεί σε μια από ένα σύνολο προτεινόμενων τιμών.

37  Ασφάλεια ◦ Οι επιλεγμένη τιμή πρέπει να είναι από το σύνολο των προτεινόμενων. ◦ Μόνο μια τιμή μπορεί να επιλεχτεί. ◦ Μια διεργασία δεν μαθαίνει ποτέ ότι μια τιμή έχει επιλεχτεί μέχρις ότου επιλεχτεί.  Liveness (ζωντάνια) ◦ Τελικά κάποια τιμή πρέπει να επιλεχτεί ◦ Εάν μια τιμή επιλεχτεί, τότε σε βάθος χρόνου οι διεργασίες το μαθαίνουν.

38  Τρεις ρόλοι  Proposers: προτείνουν τιμές  Acceptors: δέχονται τιμές ◦ Δεχτή από την πλειοψηφία  τελικά επιλέγεται  Learners: μαθαίνουν το αποτέλεσμα (πχ, η τιμή που επιλέχτηκε)  Στην πράξη μια διεργασία έχει και τους τρεις ρόλους.

39  Ας έχουμε έναν acceptor ο οποίος δέχεται την πρώτη τιμή που του προτείνεται.  Τι πρόβλημα υπάρχει? P0 P1 P2 A0 V: 0 V: 10 V: 3

40  Ας έχουμε πολλαπλούς acceptors; Ο κάθε ένας δέχεται την πρώτη πρόταση και όλοι διαλέγουν την πλειοψηφία.  Τι πρόβλημα υπάρχει? P0 P1 P2 A1 A0 A2 V: 0 V: 10 V: 3

41  Εάν προταθούν τρεις τιμές? P0 P1 P2 A1 A0 A2 V: 0 V: 10 V: 3

42  Ας αφήσουμε έναν acceptor να δεχτεί πολλαπλές προτάσεις. ◦ «Ελπίδα» ότι μια από τις πολλές προτάσεις που δέχτηκε θα έχει τον ψήφο της πλειοψηφίας  Paxos: Πως διαλέγουμε μια τιμή όταν υπάρχουν πολλοί acceptors που δέχονται πολλές προτάσεις ταυτόχρονα?

43  Κάθε proposer εξασφαλίζει ότι: ◦ Εάν μια πρόταση με τιμή V επιλεχτεί, τότε όλες οι επόμενες προτάσεις θα έχουν την ίδια τιμή V. ◦ Άπαξ και μια τιμή επιλεχτεί, καμία επόμενη πρόταση δεν μπορεί να αλλάξει το αποτέλεσμα. ◦ Αυτό επιτρέπει πολλαπλές προτάσεις να επιλεχτούν, εξασφαλίζοντας ότι όλες οι προτάσεις που τελικά θα επιλεχτούν θα έχουν την ίδια τιμή.

44  Μία πρόταση τώρα έχει δύο τιμές, και όχι μια, (proposal #, value) == (N, V)  Μια πρόταση αποτελείται από 2 πεδία (proposal #, value) == (N, V) ◦ (Σε γενικές γραμμές) ένα proposal id για κάθε τιμή που προτείνεται ◦ Το proposal # είναι αυστηρά αυξανόμενο και καθολικά μοναδικό σε όλους τους proposers. ◦ Παρόλα αυτά επιλέγει μια μόνο τιμή  Πρωτόκολλο σε 3 φάσεις

45  Ένας proposer διαλέγει ένα proposal id N και στέλνει ένα prepare request στους acceptors.  Οι Acceptors χρειάζεται να απαντήσουν με: ◦ Μια υπόσχεση ότι δεν θα δεχτούν άλλη πρόταση που έχει αριθμό λιγότερο από N ποτέ (για να εξασφαλιστεί ότι το πρωτόκολλο δεν θα ασχοληθεί με παλαιότερες προτάσεις) ◦ Εάν υπάρχει, την τιμή της αποδεκτής πρότασης με το proposal id μικρότερο ή ίσο του Ν.

46  Εάν ένας proposer λάβει μια απάντηση από την πλειοψηφία, στέλνει ένα accept request με την πρόταση (N, V) ◦ V: το V από την πρόταση Ν με τον μεγαλύτερο αριθμό από τις απαντήσεις (δηλαδή τις αποδεκτές προτάσεις που επιστρέψανε οι acceptors από την φάση 1) ◦ Ή, εάν καμία αποδεκτή πρόταση δεν επέστρεψε από την φάση 1, οποιαδήποτε νέα τιμή για το V.  Λαμβάνοντας ένα (N, V), οι acceptors είτε: ◦ Το δέχονται ◦ Το απορρίπτουν εάν υπήρξε ένα άλλο prepare request με αριθμό μεγαλύτερο από Ν, και το απάντησαν.

47  Οι Learners πρέπει να μάθουν ποια τιμή τελικά επιλέχτηκε.  Πολλοί τρόποι να το πετύχουν:  Πχ: κάθε acceptor το στέλνει σε όλους τους learners ◦ Αποτελεσματικό αλλά ακριβό  Άλλος τρόπος: Εκλογή ενός “distinguished learner” ◦ Οι Acceptors στέλνουν τα accept τους σε αυτό το process ◦ Ο distinguished learner ενημερώνει τους υπόλοιπους. ◦ Μη ανεκτικό στα σφάλματα  Μίξη και των 2: ένα σετ από distinguished learners

48  Race condition for proposals.  P0 τελειώνει την φάση1 με proposal number N0  Πριν ο P0 ξεκινήσει την φάση 2, ο P1 ξεκινά και ολοκληρώνει την phase 1 με proposal number N1 > N0.  Ο P0 κάνει την phase 2, και οι acceptors reject.  Πριν ο P1 ξεκινήσει την phase 2, ο P0 ξαναξεκινάει και τερματίζει την φάση 1 με proposal number N2 > N1.  P1 κάνει την φάση 2, οι acceptors κάνουν reject.  …(Αυτό πάει για πάντα)

49  Λύση: Εκλογή ενός distinguished proposer ◦ I.e., μόνο ένας proposer  Εάν ο distinguished proposer μπορεί να επικοινωνήσει με την πλειοψηφία, το πρωτόκολλο εγγυάται liveness. ◦ Πχ, εάν μια διεργασία παίζει τρεις ρόλους, το Paxos αντέχει αστοχίες των f < 1/2 * N servers.  Η εκλογή του leader δεν έχει λυθεί (άλλο πρόβλημα αυτό).

50 W Chosen client Propose X consensus box client Propose W W Chosen  collects proposed values  Picks one proposed value  remembers it forever

51  Get consensus on TM’s decision.  TM just learns consensus value.  TM is “stateless” RM Propose Prepared Prepared Chosen consensus box Prepared Chosen Prepared RequestCommit Prepare Commit client TMRM TM Request Commit Prepare Commit Propose Prepared Prepared Chosen

52  Get consensus on each RM’s choice.  TM just combines consensus values.  TM is “stateless” RM RM1 Prepared Chosen RM2 Prepared Chosen RequestCommit Prepare Commit client TM Request Commit Prepare Commit consensus box consensus box Propose RM2 Prepared Propose RM1 Prepared RM2 Prepared Chosen Propose RM2 Prepared

53 Prepared Chosen Prepared Prepare Commit Propose Prepared RM1 Prepared Chosen Prepare Commit Propose RM1 Prepared RM2 Prepared Chosen Propose RM2 Prepared The Obvious ApproachPaxos Commit One fewer message delay

54 RM TM acceptor Consensus box Propose RM Prepared  The normal (failure-free) case  Two message delays  Can optimize Propose RM Prepared Vote RM Prepared RM Prepare d Chosen

55 RM TM acceptor Consensus box TM TM can always learn what was chosen, or get Aborted chosen if nothing chosen yet; if majority of acceptors working.

56  Subtle.  More weird cases than most people imagine.  Proved correct.

57  N RMs  2F+1 acceptors (~2F+1 TMs)  If F+1 acceptors see all RMs prepared, then transaction committed.  2F(N+1) + 3N + 1 messages 5 message delays 2 stable write delays. Client TM RM1…N Acceptors 0…2F request commit prepare prepared all prepared commit

58  Two-Phase Commit ◦ 3N+1 messages ◦ N+1 stable writes ◦ 4 message delays ◦ 2 stable-write delays  Availability is compromised  Paxos Commit ◦ 3N+ 2F(N+1) +1 messages ◦ N+2F+1 stable writes ◦ 5 message delays ◦ 2 stable-write delays  Tolerates F Faults  Paxos ≡ 2PC for F = 0 Paxos Algorithm is the basis of Google’s Global Distributed Lock Manager ◦ Chubby has F=2 (5 Acceptors)

59  Paxos ◦ A consensus algorithm ◦ Handles crash-stop failures (f < 1/2 * N)  Three phases ◦ Phase 1: prepare request/reply ◦ Phase 2: accept request/reply ◦ Phase 3: learning of the chosen value

60  http://en.wikipedia.org/wiki/Lamport_timest amps http://en.wikipedia.org/wiki/Lamport_timest amps  Lamport, L. (1978). "Time, clocks, and the ordering of events in a distributed system". Communications of the ACM 21 (7): 558–565.  http://research.microsoft.com/users/lamport/pubs /time-clocks.pdf http://research.microsoft.com/users/lamport/pubs /time-clocks.pdf  http://en.wikipedia.org/wiki/Paxos_%28comp uter_science%29 http://en.wikipedia.org/wiki/Paxos_%28comp uter_science%29

61  Lamport, Leslie (2001). Paxos Made Simple ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001) 51-58  http://research.microsoft.com/en- us/um/people/lamport/pubs/paxos-simple.pdf http://research.microsoft.com/en- us/um/people/lamport/pubs/paxos-simple.pdf

62