User:TarkusTheTediousTaciturn/sandbox

In database systems, durability is the ACID property that guarantees that the effects of transactions that have been committed will survive permanently, even in case of failures{{Cite journal |last=Gray |first=Jim |date=1981 |title=The transaction concept: Virtues and limitations. |url=http://people.eecs.berkeley.edu/~kubitron/courses/cs262a-F21/handouts/papers/theTransactionConcept.pdf |journal=VLDB |volume=81 |pages=144-154}}, including incidents and catastrophic events. For example, if a flight booking reports that a seat has successfully been booked, then the seat will remain booked even if the system crashes.{{cite web |title=ACID Compliance: What It Means and Why You Should Care |url=https://mariadb.com/resources/blog/acid-compliance-what-it-means-and-why-you-should-care/ |website=MariaDB |date=29 July 2018 |access-date=22 September 2021}}

Formally, a database system ensures the durability property if it tolerates three types of failures: transaction, system, and media failures. In particular, a transaction fails if its execution is interrupted before all its operations have been processed by the system{{Cite journal |last=Hadzilacos |first=Vassos |date=1988 |title=A theory of reliability in database systems |url=https://dl.acm.org/doi/10.1145/42267.42272 |journal=Journal of the ACM |language=en |volume=35 |issue=1 |pages=121–145 |doi=10.1145/42267.42272 |issn=0004-5411}}. These kinds of interruptions can be originated at the transaction level by data-entry errors, operator cancellation, timeout, or application-specific errors, like withdrawing money from a bank account with insufficient funds. At system level, a failure occurs if the contents of the volatile storage are lost, due, for instance, to system crashes, like out-of-memory events. At media level, where with media is intended a stable storage that withstands system failures, failures happen when the stable storage, or part of it, is lost. These cases are typically represented by disk failures.

Thus, to be durable, the database system shall implement strategies and operations that guarantee that the effects of transactions that have been committed before the failure will survive the event (even by reconstruction), while the changes of incomplete transactions, which have not committed yet at the time of failure, will be reverted and will not affect the state of the database system. These behaviours are proven to be correct when the execution of transactions has respectively the resilience and recoverability properties.

Mechanisms

File:Database failure states and relations.png showing possible DBMS after-failure (in red) states and the transitions (in black) necessary to return to a running system to achieve durability.|350x350px]]

In transaction-based systems, the mechanisms that assure durability are historically associated with the concept of reliability of systems, as proposed by Jim Gray in 1981. This concept includes durability, but it also relies on aspects of the atomicity and consistency properties{{Cite book |title=Database systems: concepts, languages & architectures |date=1999 |publisher=McGraw-Hill |isbn=978-0-07-709500-0 |editor-last=Atzeni |editor-first=Paolo |location=New York |pages=311-320}}. Specifically, a reliability mechanism requires primitives that explicitly state the beginning, the end, and the rollback of transactions, which are also implied for the other two aforementioned properties. In this article, only the mechanisms strictly related to durability have been considered. These mechanisms are divided into three levels: transaction, system, and media level, as scenarios where failures could happen and that have to be considered in the design of database systems to address durability.

= Transaction level =

Durability against failures that occur at transaction level, such as canceled calls and inconsistent actions that may be blocked before committing by constraints and triggers, is guaranteed by the serializability property of the execution of transactions. The state generated by the effects of precedently committed transactions is available in main memory and, thus, is resilient, while the changes carried by non-committed transactions can be undone, since, thanks to serializability, they can be discerned from other transactions and, therefore, their changes are discarded. In addition, it is relevant to consider that in-place changes, which overwrite old values without keeping any kind of history are discouraged. There exist multiple approaches that keep track of the history of changes, such as timestamp-based solutions{{Cite journal |last=Svobodova |first=L. |date=1980 |title=MANAGEMENT OF OBJECT HISTORIES IN THE SWALLOW REPOSITORY |url=https://dl.acm.org/doi/10.5555/889850 |journal=MIT/LCS TR-243 |location=USA |doi=}} or logging and locking.

= System level =

At system level, failures happen, by definition, when the contents of the volatile storage are lost. This can occur in events like system crashes or power outages. Existing database systems use volatile storage (i.e. the main memory of the system) for different purposes: some store all their state and data in it, even without any durability guarantee; others keep the state and the data, or part of them, in memory, but also use the non-volatile storage for data; other systems only keep the state in main memory, while keeping all the data on disk{{Cite book |last=Petrov |first=Oleksandr |title=Database internals: a deep dive into how distributed data systems work |date=2019 |publisher=O'Reilly |isbn=978-1-4920-4034-7 |edition=1st |location=Beijing Boston Farnham Sebastopol Tokyo |pages=40-42}}. The reason behind the choice of having volatile storage, which is subject to this type of failure, and non-volatile storage is found in the performance differences of the existing technologies that are used to implement these kinds of storage, but the situation is likely to evolve as the popularity of non-volatile memories (NVM) technologies grows{{Cite journal |last=Arulraj |first=Joy |last2=Pavlo |first2=Andrew |date=2017-05-09 |title=How to Build a Non-Volatile Memory Database Management System |url=https://dl.acm.org/doi/10.1145/3035918.3054780 |journal=Proceedings of the 2017 ACM International Conference on Management of Data |series=SIGMOD '17 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=1753–1758 |doi=10.1145/3035918.3054780 |isbn=978-1-4503-4197-4}}.

In systems that include non-volatile storage, durability can be achieved by keeping and flushing an immutable sequential log of the transactions to such non-volatile storage before acknowledging commitment. Thanks to their atomicity property, the transactions can be considered the unit of work in the recovery process that guarantees durability while exploiting the log. In particular, the logging mechanism is called write-ahead log (WAL) and allows durability by buffering changes to the disk before they are synchronized from the main memory. In this way, by reconstruction from the log file, all committed transactions are resilient to system-level failures, because they can be redone. Non-committed transactions, instead, are recoverable, since their operations are logged to non-volatile storage before they effectively modify the state of the database{{Cite book |last=Petrov |first=Oleksandr |title=Database internals: a deep dive into how distributed data systems work |date=2019 |publisher=O'Reilly |isbn=978-1-4920-4034-7 |edition=1st |location=Beijing Boston Farnham Sebastopol Tokyo |pages=185-195}}. In this way, the partially executed operations can be undone without affecting the state of the system. After that, those transactions that were incomplete can be redone. Therefore, the transaction log from non-volatile storage can be reprocessed to recreate the system state right before any later system-level failure. It is worth mentioning that logging is done as a combination of tracking data and operations (i.e. transactions) for performance reasons{{Cite journal |last=Mohan |first=C. |last2=Haderle |first2=Don |last3=Lindsay |first3=Bruce |last4=Pirahesh |first4=Hamid |last5=Schwarz |first5=Peter |date=1992-03-01 |title=ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging |url=https://dl.acm.org/doi/10.1145/128765.128770 |journal=ACM Transactions on Database Systems |volume=17 |issue=1 |pages=94–162 |doi=10.1145/128765.128770 |issn=0362-5915}}.

= Media level =

At media level, failure scenarios affect non-volatile storage, like hard disk drives, solid-state drives, and other types of storage hardware components. To guarantee durability at this level, the database system shall rely on stable memory, that is, a memory that is completely and ideally failure-resistant. This kind of memory can be achieved with mechanisms of replication and robust writing protocols.

Many tools and technologies are available to provide a logical stable memory, such as the mirroring of disks, and their choice depends on the requirements of the specific applications. In general, replication and redundancy strategies and architectures that behave like stable memory are available at different levels of the technology stack. In this way, even in case of catastrophic events where the storage hardware is damaged, data loss can be prevented{{Cite journal |last=Eich |first=Margaret H. |date=1987-02-01 |title=A classification and comparison of main memory database recovery techniques |url=http://ieeexplore.ieee.org/document/7272398/ |journal=IEEE Third International Conference on Data Engineering |publisher=IEEE |pages=332–339 |doi=10.1109/ICDE.1987.7272398 |isbn=978-0-8186-0762-2}}. At this level, there is a strong bond between durability and system and data recovery, in the sense that the main goal is to preserve the data, not necessarily in online replicas, but also as offline copies. These last techniques fall into the categories of backup, data loss prevention, and disaster recovery{{Cite journal |last=Choy |first=Manhoi |last2=Leong |first2=Hong Va |last3=Wong |first3=Man Hon |date=2000 |title=Disaster recovery techniques for database systems |url=https://dl.acm.org/doi/10.1145/352515.352521 |journal=Communications of the ACM |language=en |volume=43 |issue=11es |pages=6 |doi=10.1145/352515.352521 |issn=0001-0782}}.

Therefore, in case of media failure, the durability of transactions is guaranteed by the ability to reconstruct the state of the database from the log files stored in the stable memory, in any way it was implemented in the database system. There exist several mechanisms to store and reconstruct the state of a database system that improves the performance, both in terms of space and time, compared to managing all the log files created from the beginning of the database system. These mechanisms often include incremental dumping, differential files, and checkpoints{{Cite journal |last=Verhofstad |first=Joost S. M. |date=1978-06-01 |title=Recovery Techniques for Database Systems |url=http://portal.acm.org/citation.cfm?doid=356725.356730 |journal=ACM Computing Surveys |volume=10 |issue=2 |pages=167–195 |doi=10.1145/356725.356730}}.

=Distributed databases=

In distributed transactions, ensuring durability requires additional mechanisms to preserve a consistent state sequence across all database nodes. This means, for example, that a single node may not be enough to decide to conclude a transaction by committing it, since the resources used in that transaction may be on other nodes, where other transactions are occurring concurrently. Otherwise, in case of failure, if consistency could not be guaranteed, it would be impossible to acknowledge a safe state of the database for recovery. For this reason, all participating nodes must coordinate before a commit can be acknowledged. This is usually done by a two-phase commit protocol{{Cite journal |last=Mohan |first=C. |last2=Haderle |first2=Don |last3=Lindsay |first3=Bruce |last4=Pirahesh |first4=Hamid |last5=Schwarz |first5=Peter |date=1992-03-01 |title=ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging |url=https://dl.acm.org/doi/10.1145/128765.128770 |journal=ACM Transactions on Database Systems |volume=17 |issue=1 |pages=94–162 |doi=10.1145/128765.128770 |issn=0362-5915}}.

In addition, in distributed databases, even the protocols for logging and recovery shall address the issues of distributed environments, such as deadlocks, that could prevent the resilience and recoverability of transactions and, thus, durability. A widely adopted family of algorithms that ensures these properties is Algorithms for Recovery and Isolation Exploiting Semantics (ARIES).

References

External links

[https://docs.oracle.com/en/database/other-databases/nosql-database/22.1/concepts/durability.html#GUID-744DA3DD-A2E5-418B-BC97-6749E5294BB7 Durability aspects in Oracle's databases]
[https://dev.mysql.com/doc/refman/8.0/en/mysql-acid.html MySQL InnoDB documentation on support of ACID properties]
[https://www.postgresql.org/docs/current/wal-reliability.html PostgreSQL's documentation on reliability]
[https://learn.microsoft.com/en-us/sql/relational-databases/logs/control-transaction-durability?view=sql-server-ver16 Microsoft SQL Server Control Transaction Durability]
[https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html Interactive latency visualization for different types of storages from Berkeley]