The Case for DBMS Live Patching [Extended Version]

TL;DR

This paper explores live patching for DBMSs, proposing domain-specific strategies for in-memory code updates without system restart, and evaluates their impact on performance and latency.

Contribution

It introduces domain-specific techniques for safe live patching in DBMSs and provides an experimental analysis of their effects on throughput and latency.

Findings

Live patching can be viable for DBMS updates.

Quiescence strategies impact transaction throughput.

Latency overhead varies with patching methods.

Abstract

Traditionally, when the code of a database management system (DBMS) needs to be updated, the system is restarted and database clients suffer downtime, or the provider instantiates hot-standby instances and rolls over the workload. We investigate a third option, live patching of the DBMS binary. For certain code changes, live patching allows to modify the application code in memory, without restart. The memory state and all client connections can be maintained. Although live patching has been explored in the operating systems research community, it remains a blind spot in DBMS research. In this Experiment, Analysis & Benchmark article, we systematically explore this field from the DBMS perspective. We discuss what distinguishes database management systems from generic multi-threaded applications when it comes to live patching. We then propose domain-specific strategies for injecting quiescence points into the DBMS source code, so that threads can safely migrate to the patched process version. We experimentally investigate the interplay between the query workload and different quiescence methods, monitoring both transaction throughput and tail latencies. We show that live patching can be a viable option for updating database management systems, since database providers can make informed decisions w.r.t. the latency overhead on the client side.