%0 Conference Proceedings
%T Transactional Failure Recovery for a Distributed Key-Value Store
%+ McGill University = Université McGill [Montréal, Canada]
%+ Universidad Politécnica de Madrid (UPM)
%A Ahmad, Muhammad, Yousuf
%A Kemme, Bettina
%A Brondino, Ivan
%A Patiño-Martínez, Marta
%A Jiménez-Peris, Ricardo
%Z Part 3: Storage
%< avec comité de lecture
%( Lecture Notes in Computer Science
%B 14th International Middleware Conference (Middleware)
%C Beijing, China
%Y David Hutchison
%Y Takeo Kanade
%Y Madhu Sudan
%Y Demetri Terzopoulos
%Y Doug Tygar
%Y Moshe Y. Vardi
%Y Gerhard Weikum
%Y David Eyers
%Y Karsten Schwan
%Y Josef Kittler
%Y Jon M. Kleinberg
%Y Friedemann Mattern
%Y John C. Mitchell
%Y Moni Naor
%Y Oscar Nierstrasz
%Y C. Pandu Rangan
%Y Bernhard Steffen
%I Springer
%3 Middleware 2013
%V LNCS-8275
%P 267-286
%8 2013-12-09
%D 2013
%R 10.1007/978-3-642-45065-5_14
%K Cloud computing
%K key-value store
%K transaction processing
%K OLTP
%K fault tolerance
%K failure recovery
%Z Computer Science [cs]
%Z Computer Science [cs]/Networking and Internet Architecture [cs.NI]Conference papers
%X With the advent of cloud computing, many applications have embraced the ensuing paradigm shift towards modern distributed key-value data stores, like HBase, in order to benefit from the elastic scalability on offer. However, many applications still hesitate to make the leap from the traditional relational database model simply because they cannot compromise on the standard transactional guarantees of atomicity, isolation, and durability. To get the best of both worlds, one option is to integrate an independent transaction management component with a distributed key-value store. In this paper, we discuss the implications of this approach for durability. In particular, if the transaction manager provides durability (e.g., through logging), then we can relax durability constraints in the key-value store. However, if a component fails (e.g., a client or a key-value server), then we need a coordinated recovery procedure to ensure that commits are persisted correctly. In our research, we integrate an independent transaction manager with HBase. Our main contribution is a failure recovery middleware for the integrated system, which tracks the progress of each commit as it is flushed down by the client and persisted within HBase, so that we can recover reliably from failures. During recovery, commits that were interrupted by the failure are replayed from the transaction management log. Importantly, the recovery process does not interrupt transaction processing on the available servers. Using a benchmark, we evaluate the impact of component failure, and subsequent recovery, on application performance.
%G English
%Z TC 6
%Z WG 6.1
%2 https://inria.hal.science/hal-01480780/document
%2 https://inria.hal.science/hal-01480780/file/978-3-642-45065-5_14_Chapter.pdf
%L hal-01480780
%U https://inria.hal.science/hal-01480780
%~ IFIP-LNCS
%~ IFIP
%~ IFIP-TC
%~ IFIP-WG
%~ IFIP-TC6
%~ IFIP-WG6-1
%~ IFIP-LNCS-8275
%~ IFIP-MIDDLEWARE