CPS 512 midterm exam #1, 10/7/2016 Your name please: ___________________ NetID:___________ /60 /40 /10.

Slides:



Advertisements
Similar presentations
Two phase commit. Failures in a distributed system Consistency requires agreement among multiple servers –Is transaction X committed? –Have all servers.
Advertisements

TRANSACTION PROCESSING SYSTEM ROHIT KHOKHER. TRANSACTION RECOVERY TRANSACTION RECOVERY TRANSACTION STATES SERIALIZABILITY CONFLICT SERIALIZABILITY VIEW.
CS542: Topics in Distributed Systems Distributed Transactions and Two Phase Commit Protocol.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Replication Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Systems Fall 2010 Replication Fall 20105DV0203 Outline Group communication Fault-tolerant services –Passive and active replication Highly.
E-Transactions: End-to-End Reliability for Three-Tier Architectures Svend Frølund and Rachid Guerraoui.
Transaction Processing Lecture ACID 2 phase commit.
Database Replication techniques: a Three Parameter Classification Authors : Database Replication techniques: a Three Parameter Classification Authors :
CS 582 / CMPE 481 Distributed Systems
Sinfonia: A New Paradigm for Building Scalable Distributed Systems Marcos K. Aguilera, Arif Merchant, Mehul Shah, Alistair Veitch, Christonos Karamanolis.
1 ICS 214B: Transaction Processing and Distributed Data Management Replication Techniques.
Distributed Systems Fall 2009 Replication Fall 20095DV0203 Outline Group communication Fault-tolerant services –Passive and active replication Highly.
1 ICS 214B: Transaction Processing and Distributed Data Management Distributed Database Systems.
Commit Protocols. CS5204 – Operating Systems2 Fault Tolerance Causes of failure: process failure machine failure network failure Goals : transparent:
CS162 Section Lecture 10 Slides based from Lecture and
Distributed Transactions March 15, Transactions What is a Distributed Transaction?  A transaction that involves more than one server  Network.
CSE 486/586 CSE 486/586 Distributed Systems Concurrency Control Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Concurrency Control Steve Ko Computer Sciences and Engineering University at Buffalo.
Operating Systems Distributed Coordination. Topics –Event Ordering –Mutual Exclusion –Atomicity –Concurrency Control Topics –Event Ordering –Mutual Exclusion.
Eduardo Gutarra Velez. Outline Distributed Filesystems Motivation Google Filesystem Architecture The Metadata Consistency Model File Mutation.
Commit Algorithms Hamid Al-Hamadi CS 5204 November 17, 2009.
Introduction to Distributed Databases Yiwei Wu. Introduction A distributed database is a database in which portions of the database are stored on multiple.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Replication Steve Ko Computer Sciences and Engineering University at Buffalo.
Part 1. Managing replicated server groups These questions pertain to managing server groups with replication, as in e.g., Chubby, Dynamo, and the classical.
Multidatabase Transaction Management COP5711. Multidatabase Transaction Management Outline Review - Transaction Processing Multidatabase Transaction Management.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Transactions on Replicated Data Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Transactions What is a transaction? (A sequence of server operations that must be carried out atomically ) ACID properties - what are these.
Distributed Databases – Advanced Concepts Chapter 25 in Textbook.
CPS 512/590 final exam, 12/8/2015 /60 Your name please: /50 /50 /60
Recovery in Distributed Systems:
/50 /60 /40 /30 A Tale of Two Clients
CS 245: Database System Principles Notes 11: Modern and Distributed Transactions Peter Bailis CS 245 Notes 11.
CSE 486/586 Distributed Systems Consistency --- 1
CSCI5570 Large Scale Data Processing Systems
CPS 512/590 second midterm exam, 11/3/2015
Introduction to NewSQL
Two phase commit.
Distributed Transactions and Spanner
Replication Control II Reading: Chapter 15 (relevant parts)
View Change Protocols and Reconfiguration
EECS 498 Introduction to Distributed Systems Fall 2017
IS 651: Distributed Systems Consensus
EECS 498 Introduction to Distributed Systems Fall 2017
EECS 498 Introduction to Distributed Systems Fall 2017
Commit Protocols CS60002: Distributed Systems
RELIABILITY.
Outline Announcements Fault Tolerance.
EECS 498 Introduction to Distributed Systems Fall 2017
CSE 486/586 Distributed Systems Consistency --- 1
EECS 498 Introduction to Distributed Systems Fall 2017
Replication and Recovery in Distributed Systems
From Viewstamped Replication to BFT
CSE 486/586 Distributed Systems Concurrency Control --- 3
IS 651: Distributed Systems Fault Tolerance
Scalable Causal Consistency
Distributed Transactions
Lecture 21: Replication Control
Atomic Commit and Concurrency Control
EECS 498 Introduction to Distributed Systems Fall 2017
IS 651: Distributed Systems Final Exam
Causal Consistency and Two-Phase Commit
Lecture 20: Intro to Transactions & Logging II
Distributed Databases Recovery
View Change Protocols and Reconfiguration
Lecture 21: Replication Control
Implementing Consistency -- Paxos
CSE 486/586 Distributed Systems Concurrency Control --- 3
Transaction Communication
Transactions, Properties of Transactions
Presentation transcript:

CPS 512 midterm exam #1, 10/7/2016 Your name please: ___________________ NetID:___________ /60 /40 /10 /10 Answer all questions. Please attempt to confine your answers to the boxes provided. If you don’t know the answer to a question, then just say something else relevant for partial credit. T/Fs and shorts are 5 points each. /20 /60 P1. Transactions: T/F (60 points) Indicate whether each statement is true or false by placing a T or F to the left of the statement. You can place additional notes or conditions to the right. /200 In the two-phase commit protocol (2PC), a transaction T always commits if a majority of participants vote to commit T. Commitment is durable in client-server transaction systems with 2PC, as long as a majority of participants survive and retain their state, even in the presence of a network partition. When a transaction T commits with 2PC, there is always some point in the protocol at which all participants have voted, but no participant knows the outcome of T. When a transaction T commits with 2PC and two-phase locking (2PL), each participant releases locks held by T when it votes to commit T. Failure of the coordinator during a two-phase commit (2PC) never forces the transaction to abort. Failure of a participant other than the coordinator during a 2PC (failure of a storage server or RM) always forces the transaction to abort. In client-server transaction systems, failure of the client during a 2PC always forces the transaction to abort. In a transactional server with a NO-STEAL/NO-FORCE buffer manager (e.g., Birrell/Wobber), the server always writes updates to the log before it responds to the client. In a transactional server with a NO-STEAL/NO-FORCE buffer manager (e.g., Birrell/Wobber), the server does not write updates to the file system until after it has responded to the client. In a transactional server with a NO-STEAL/NO-FORCE buffer manager (e.g., Birrell/Wobber), taking checkpoints (snapshots) more frequently increases the cost of recovery. In a transactional server with logging, each update record in the log must identify the transaction that issued the update. Any transactional service is linearizable if each request is executed at most once.

CPS 512 first midterm exam, 10/7/2016, page 2 of 4 P2. More T/Fs on Consensus and Consistency (40 points) Indicate whether each statement is true or false by placing a T or F to the left of the statement. You can place additional notes or conditions to the right. Consensus refers to Paxos, Viewstamped Replication (VR), or Raft. These protocols are used for primary/backup replication, e.g., Replicated State Machine (RSM) replication. In Consensus, any partition in the network always results in denial of service (no availability) on at least one side of the network partition. In Consensus, any partition in the network always results in denial of service (no availability) on at most one side of the network partition. In Consensus, no participant (other than the primary) executes a request until all participants have voted on it. In Consensus an operation always commits if the majority of participants vote to commit it. Commitment is durable in Consensus replication as long as a majority of participants survive and retain their state, even in the presence of a network partition. A Chubby client can be in jeopardy only after it acquires a session lease at least once. Any service that is replicated with Consensus is linearizable if each request is executed at most once. Any service is linearizable if each request is executed at most once. P3. Replicated State Machine (10 points) Please confine your answers to the space provided. The Replicated State Machine (RSM) model of primary-backup replication with Consensus does not scale: it does not yield higher throughput as we add servers. Why? What could go wrong if we permit any RSM replica to act as the coordinator for a write operation? What could go wrong if we permit RSM backup servers to execute read operations?

CPS 512 first midterm exam, 10/7/2016, page 3 of 4 P4. Chubby (10 points) Answer each question with a sentence or a short bullet list. Please confine your answers to the space provided. Chubby is a coordination service that uses primary-backup replication with Consensus, and yet it claims to be scalable to large numbers of clients. How does it overcome the scaling limitation? When a Chubby server receives a request to update an object/node, it may send messages to other servers in its cell and to other clients before completing the request. List three reasons for these messages. P5. RAMcloud (20 points) Answer each question with a sentence or a short bullet list. Please confine your answers to the space provided. RAMcloud is a key-value store that uses primary-backup replication with Consensus, and yet it claims to be scalable to large (datacenter) server clusters. How does it overcome the scaling limitation? RAMcloud uses RIFL, which provides stronger linearizability assurances than classic RPC (e.g., Birrell/Nelson) because completion records are durable. Sketch an example to show a scenario in which loss of a completion records can lead to a violation of linearizability in classic RPC. RIFL has higher latency than classic RPC, because the completion record for each RPC must be made durable (e.g., by writing it to disk) before issuing a reply to the client. Yet the authors of RIFL claim that the latency cost is negligible for services that support fail-over. Why is the latency cost negligible for these services?

CPS 512 first midterm exam, 10/7/2016, page 4 of 4 P6. Sharding (20 points) Given a scalable key-value store (like RAMcloud), any application-tier server (the clients of the K/V store) can access any of the service's data, so in principle any application server can handle any request. Yet many services apply a request routing function to route each request to a selected application server based on the data used by the request: sharding. Give two reasons why sharding can be helpful in the application tier in this setting. P7. Abstraction boundary (20 points) In modern distributed services, the API that the application sees is typically different from the RPC API for the service. Why? Illustrate with examples from NFS, Chubby, RAMcloud/RIFL, and other services we have discussed. P8. Serializability vs. Concurrency (20 points) Transactional serializability does not imply serial execution. Give a specific example of two transactions for which any interleaving of operations is a serializable execution.