Constant time recovery in Azure SQL database

Antonopoulos, Panagiotis; Byrne, Peter; Chen, Wayne; Diaconu, Cristian; Kodandaramaih, Raghavendra Thallam; Kodavalla, Hanuma; Purnananda, Prashanth; Radu, Adrian-Leonard; Ravella, Chaitanya Sreenivas; Venkataramanappa, Girish Mittur

doi:10.14778/3352063.3352131

Cited by 16 publications

(7 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Instant recovery [16] is a family of algorithms that allow new transactions to execute immediately after a system or even media failure, including localized single-page corruptions. A complementary technique is constant-time recovery [3], which exploits multi-version storage to allow instantaneous undo of arbitrarily long user transactions. Since both techniques rely on physiological logging, they can be combined with our approach to achieve efficient logging and checkpointing as well as faster recovery.…”

Section: Related Workmentioning

confidence: 99%

Rethinking Logging, Checkpoints, and Recovery for High-Performance Storage Engines

Haubenschild

Sauer

Neumann

et al. 2020

Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data

View full text Add to dashboard Cite

For decades, ARIES has been the standard for logging and recovery in database systems. ARIES offers important features like support for arbitrary workloads, fuzzy checkpoints, and transparent index recovery. Nevertheless, many modern inmemory database systems use more lightweight approaches that have less overhead and better multi-core scalability but only work well for the in-memory setting. Recently, a new class of high-performance storage engines has emerged, which exploit fast SSDs to achieve performance close to pure in-memory systems but also allow out-of-memory workloads. For these systems, ARIES is too slow whereas inmemory logging proposals are not applicable. In this work, we propose a new logging and recovery design that supports incremental and fuzzy checkpointing, index recovery, out-of-memory workloads, and low-latency transaction commits. Our continuous checkpointing algorithm guarantees bounded recovery time. Using per-thread logging with minimal synchronization, our implementation achieves near-linear scalability on multi-core CPUs. We implemented and evaluated these techniques in our LeanStore storage engine. For working sets that fit in main memory, we achieve performance close to that of an in-memory approach, even with logging, checkpointing, and dirty page writing enabled. For the out-of-memory scenario, we outperform a state-of-the-art ARIES implementation by a factor of two.

show abstract

Section: Related Workmentioning

confidence: 99%

Rethinking Logging, Checkpoints, and Recovery for High-Performance Storage Engines

Haubenschild

Sauer

Neumann

et al. 2020

Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data

View full text Add to dashboard Cite

show abstract

“…Each element of LV indicates that a transaction T may depend on transactions before a certain position in the corresponding log. Specifically, given a transaction T and its assigned LV: T.LV = (𝐿𝑉 [1], 𝐿𝑉 [2], . .…”

Section: Lsn Vectormentioning

confidence: 99%

“…WLOG, we assume T1 and T2 are assigned to Log 1 and T3 is assigned to Log 2. In the beginning, A has a writeLV [4,2] and a readLV [3,7] while object B has [8,6] and [5,11]. 1 The DBMS initializes the transactions' LV s as [0,0].…”

Section: Logging Operationsmentioning

confidence: 99%

“…During recovery, Fig. 4b shows that Taurus fills in the blanks with the most recently seen anchor, LPLV = [7,16,2,4]. The compressed LV is decoded into [7,45,2,4].…”

Section: Optimization: LV Compressionmentioning

confidence: 99%

“…4b shows that Taurus fills in the blanks with the most recently seen anchor, LPLV = [7,16,2,4]. The compressed LV is decoded into [7,45,2,4]. Note that the 1 𝑠𝑡 , 3 𝑟𝑑 , and 4 𝑡ℎ dimension of the decompressed LV are greater than the original T.LV.…”

Section: Optimization: LV Compressionmentioning

confidence: 99%

See 2 more Smart Citations

Taurus

Xia

Pavlo

et al. 2020

Proc. VLDB Endow.

View full text Add to dashboard Cite

Existing single-stream logging schemes are unsuitable for in-memory database management systems (DBMSs) as the single log is often a performance bottleneck. To overcome this problem, we present Taurus, an efficient parallel logging scheme that uses multiple log streams, and is compatible with both data and command logging. Taurus tracks and encodes transaction dependencies using a vector of log sequence numbers (LSNs). These vectors ensure that the dependencies are fully captured in logging and correctly enforced in recovery. Our experimental evaluation with an in-memory DBMS shows that Taurus's parallel logging achieves up to 9.9X and 2.9X speedups over single-streamed data logging and command logging, respectively. It also enables the DBMS to recover up to 22.9X and 75.6X faster than these baselines for data and command logging, respectively. We also compare Taurus with two state-of-the-art parallel logging schemes and show that the DBMS achieves up to 2.8X better performance on NVMe drives and 9.2X on HDDs.

show abstract