Distributed Transactions and Spanner

Slides:



Advertisements
Similar presentations
1 CS 194: Elections, Exclusion and Transactions Scott Shenker and Ion Stoica Computer Science Division Department of Electrical Engineering and Computer.
Advertisements

Spanner: Google’s Globally-Distributed Database James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, Sanjay Ghemawat,
Failure Detection The ping-ack failure detector in a synchronous system satisfies – A: completeness – B: accuracy – C: neither – D: both.
SPANNER: GOOGLE’S GLOBALLYDISTRIBUTED DATABASE James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, Sanjay Ghemawat,
Presented By Alon Adler – Based on OSDI ’12 (USENIX Association)
Strong Consistency and Agreement COS 461: Computer Networks Spring 2011 Mike Freedman 1 Jenkins,
Session - 14 CONCURRENCY CONTROL CONCURRENCY TECHNIQUES Matakuliah: M0184 / Pengolahan Data Distribusi Tahun: 2005 Versi:
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Vector timestamps Global state –Distributed Snapshot Election algorithms.
Spanner Lixin Shi Quiz2 Review (Some slides from Spanner’s OSDI presentation)
Spanner: Google’s Globally-Distributed Database James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman,Sanjay Ghemawat,
Concurrency control in transactional systems Jinyang Li Some slides adapted from Stonebraker and Madden.
IM NTU Distributed Information Systems 2004 Replication Management -- 1 Replication Management Yih-Kuen Tsay Dept. of Information Management National Taiwan.
Chapter 4 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University Building Dependable Distributed Systems.
EEC 688/788 Secure and Dependable Computing Lecture 9 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Google Spanner Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Systems Lecture 5 Time and synchronization 1.
Spanner: Google’s Globally Distributed Database
a journey from the simple to the optimal
Spanner Storage insights
CSE 486/586 Distributed Systems Consistency --- 1
CPS 512 midterm exam #1, 10/7/2016 Your name please: ___________________ NetID:___________ /60 /40 /10.
Strong Consistency & CAP Theorem
Concurrency control in transactional systems
Strong Consistency & CAP Theorem
Two phase commit.
Spanner: Google’s Globally-Distributed Database
Strong Consistency & CAP Theorem
View Change Protocols and Reconfiguration
COS 418: Advanced Computer Systems Lecture 5 Michael Freedman
EECS 498 Introduction to Distributed Systems Fall 2017
MVCC and Distributed Txns (Spanner)
Replication and Consistency
Concurrency Control II (OCC, MVCC) and Distributed Transactions
EECS 498 Introduction to Distributed Systems Fall 2017
EECS 498 Introduction to Distributed Systems Fall 2017
EECS 498 Introduction to Distributed Systems Fall 2017
EECS 498 Introduction to Distributed Systems Fall 2017
Spanner: Google’s Globally-Distributed Database
Implementing Consistency -- Paxos
Replication and Consistency
EECS 498 Introduction to Distributed Systems Fall 2017
RELIABILITY.
Distributed Systems, Consensus and Replicated State Machines
Concurrency Control II (OCC, MVCC)
CSE 486/586 Distributed Systems Consistency --- 1
EECS 498 Introduction to Distributed Systems Fall 2017
Fault-tolerance techniques RSM, Paxos
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
Scalable Causal Consistency
Distributed Transactions
Lecture 21: Replication Control
Atomic Commit and Concurrency Control
EEC 688/788 Secure and Dependable Computing
EECS 498 Introduction to Distributed Systems Fall 2017
Concurrency Control II and Distributed Transactions
View Change Protocols and Reconfiguration
COS 418: Distributed Systems Lecture 16 Wyatt Lloyd
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
Strong Consistency & CAP Theorem
Lecture 21: Replication Control
CSE 486/586 Distributed Systems Consistency --- 2
Implementing Consistency -- Paxos
Concurrency control (OCC and MVCC)
Replication and Consistency
Presentation transcript:

Distributed Transactions and Spanner COS 418: Distributed Systems Lecture 19 Michael Freedman

Serializability  Execution of a set of transactions over multiple items is equivalent to some serial execution of txns

Distributed Transactions

Consider partitioned data over servers L R U O L R W U P L W U Q When do you release locks before commit? Carefully – like when you are traversing a data structure but not actually using the data Why not just use 2PL? Grab locks over entire read and write set Perform writes Release locks (at commit time)

Consider partitioned data over servers L R U O L R W U P L W U Q When do you release locks before commit? Carefully – like when you are traversing a data structure but not actually using the data How do you get serializability? On single machine, single COMMIT op in the WAL In distributed setting, assign global timestamp to txn (at sometime after lock acquisition and before commit) Centralized txn manager Distributed consensus on timestamp (not all ops)

Strawman: Consensus per txn group? L R U O L R W U P L W U Q When do you release locks before commit? Carefully – like when you are traversing a data structure but not actually using the data R S Single Lamport clock, consensus per group? Linearizability composes! But doesn’t solve concurrent, non-overlapping txn problem

Spanner: Google’s Globally-Distributed Database OSDI 2012

Google’s Setting Dozens of zones (datacenters) Per zone, 100-1000s of servers Per server, 100-1000 partitions (tablets) Every tablet replicated for fault-tolerance (e.g., 5x)

Scale-out vs. fault tolerance P P P Q Q Q Every tablet replicated via Paxos (with leader election) So every “operation” within transactions across tablets actually a replicated operation within Paxos RSM Paxos groups can stretch across datacenters!

Disruptive idea: Do clocks really need to be arbitrarily unsynchronized? Can you engineer some max divergence?

TrueTime “Global wall-clock time” with bounded uncertainty Timestamps become intervals, not single values TT.now() time earliest latest 2*ε Consider event enow which invoked tt = TT.new(): Guarantee: tt.earliest <= tabs(enow) <= tt.latest

Timestamps and TrueTime Acquired locks Release locks T Pick s > TT.now().latest s Wait until TT.now().earliest > s Commit wait average ε average ε

Commit Wait and Replication Start consensus Achieve consensus Notify followers Acquired locks Release locks T Pick s Commit wait done

Client-driven transactions Issues reads to leader of each tablet group, which acquires read locks and returns most recent data Locally performs writes Chooses coordinator from set of leaders, initiates commit Sends commit message to each leader, include identify of coordinator and buffered writes Waits for commit from coordinator

Commit Wait and 2-Phase Commit On commit msg from client, leaders acquire local write locks If non-coordinator: Choose prepare ts > previous local timestamps Log prepare record through Paxos Notify coordinator of prepare timestamp If coordinator: Wait until hear from other participants Choose commit timestamp >= prepare ts, > local ts Logs commit record through Paxos Wait commit-wait period Sends commit timestamp to replicas, other leaders, client All apply at commit timestamp and release locks

Commit Wait and 2-Phase Commit Acquired locks TC Acquired locks TP1 Leaders acquire local write locks If non-coordinator: Choose prepare ts > previous local timestamps Log prepare record through Paxos Notify coordinator of prepare timestamp If coordinator: Wait until hear from other participants Choose commit timestamp >= prepare ts, > local ts Logs commit record through Paxos Wait commit-wait period Sends commit timestamp to replicas, other leaders, client All apply at commit timestamp and release locks Acquired locks TP2 Compute sp for each Client issues reads to leader of each tablet group, which acquires read locks and returns most recent data

Commit Wait and 2-Phase Commit Start logging Done logging Acquired locks TC Acquired locks TP1 Leaders acquire local write locks If non-coordinator: Choose prepare ts > previous local timestamps Log prepare record through Paxos Notify coordinator of prepare timestamp If coordinator: Wait until hear from other participants Choose commit timestamp >= prepare ts, > local ts Logs commit record through Paxos Wait commit-wait period Sends commit timestamp to replicas, other leaders, client All apply at commit timestamp and release locks Acquired locks TP2 Prepared Send sp Compute sp for each Locally performs writes Chooses coordinator from set of leaders, initiates commit Sends commit msg to each leader, incl. identity of coordinator

Commit Wait and 2-Phase Commit Start logging Done logging Acquired locks Release locks TC Committed Notify participants sc Acquired locks Release locks TP1 Leaders acquire local write locks If non-coordinator: Choose prepare ts > previous local timestamps Log prepare record through Paxos Notify coordinator of prepare timestamp If coordinator: Wait until hear from other participants Choose commit timestamp >= prepare ts, > local ts Logs commit record through Paxos Wait commit-wait period Sends commit timestamp to replicas, other leaders, client All apply at commit timestamp and release locks Acquired locks Release locks TP2 Prepared Send sp Compute sp for each Commit wait done Compute overall sc Client waits for commit from coordinator

Remove X from friend list Remove myself from X’s friend list Example Remove X from friend list Risky post P TC T2 sp= 6 sc= 8 s = 15 Remove myself from X’s friend list TP sp= 8 sc= 8 Time <8 8 15 My friends [X] [] My posts [P] X’s friends [me] []

Read-only optimizations Given global timestamp, can implement read-only transactions lock-free (snapshot isolation) Step 1: Choose timestamp sread = TT.now.latest() Step 2: Snapshot read (at sread) to each tablet Can be served by any up-to-date replica

Disruptive idea: Do clocks really need to be arbitrarily unsynchronized? Can you engineer some max divergence?

TrueTime Architecture GPS timemaster GPS timemaster GPS timemaster GPS timemaster Atomic-clock timemaster GPS timemaster Client Datacenter 1 Datacenter 2 … Datacenter n Compute reference [earliest, latest] = now ± ε

TrueTime implementation now = reference now + local-clock offset ε = reference ε + worst-case local-clock drift = 1ms + 200 μs/sec time ε 0sec 30sec 60sec 90sec +6ms What about faulty clocks? Bad CPUs 6x more likely in 1 year of empirical data

Known unknowns > unknown unknowns Rethink algorithms to reason about uncertainty