Providers of high-availability data stores need to roll out software updates without causing noticeable downtimes. For distributed data stores like Redis Cluster, the state-of-the-art is a rolling update, where the nodes are restarted in sequence. This requires preserving, restoring, and resynchronizing the database state, which can significantly prolong updates for larger memory states, and thus delay critical security fixes. In this article, we propose applying software updates directly in memory without restarting any nodes. We present the first fully operational live patching solution for Redis Cluster on Linux. We support both push- and pull-based distribution of patches, trading dissemination speed against cluster elasticity, the ability to allow nodes to dynamically join or leave the cluster. Our integration is very lightweight, as it piggybacks on the cluster-internal gossip protocol. Our experiments benchmark live patching against state-of-the-art rolling updates. In one scenario, live patching updates the entire cluster orders of magnitude faster, without unfavorable trade-offs regarding throughput, tail latencies, or network consumption. To showcase generalizability, we provide general guidelines on integrating live patching for distributed database systems and successfully apply them to a primary-replica PostgreSQL setup. Given our overall promising results, we discuss the opportunities of live patching in database DevOps.

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.

Share on Live Patching Database Management Systems Author: Michael Fruth University of Passau, Passau, Germany University of Passau, Passau, GermanyView Profile Authors Info & Claims SIGMOD '22: Proceedings of the 2022 International Conference on Management of DataJune 2022 Pages 2524–2526https://doi.org/10.1145/3514221.3520253Online:11 June 2022Publication History 0citation46DownloadsMetricsTotal Citations0Total Downloads46Last 12 Months46Last 6 weeks6 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my Alerts New Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

NoSQL document stores have become vastly popular. One major selling point is their flexibility w.r.t. schema management: With MongoDB, developers can actually switch back-and-forth between operating in schema-free mode, and schema fixed mode, where all write operations are validated. In this tool demo, we present Josch, which integrates state-ofthe-art third-party tools to support novel workflows for NoSQL document stores: Using Josch, DevOps teams may (1) extract a JSON Schema declaration from the production data instance, (2) manually refactor the schema (e.g., to account for upcoming schema changes), and (3) compare the extracted and the refactored schema, on a semantic level, e.g., to ensure that the rewritten schema is a generalization. (4) Finally, they may register the refactored schema with the NoSQL document store for schema validation. Apart from supporting this and other practical use cases, one further contribution of our demo is that we reveal current blind spots in NoSQL schema management tools that inspire novel research questions.