Обеспечение долговечности данных в базах данных: механизмы и типы отказов.
Durability (database systems)
Надёжность баз данных: свойство ACID "долговечность" гарантирует сохранение данных после сбоев. Транзакции, система, ошибки – всё учтено! Логирование и блокировки.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
В системах баз данных долговечность — это свойство ACID, которое гарантирует, что последствия завершённых транзакций будут сохранены постоянно, даже в случае сбоев, включая инциденты и катастрофические события. Например, если при бронировании места в авиарейсе сообщается об успешном бронировании, то место останется забронированным, даже если система выйдет из строя. Формально, система баз данных обеспечивает свойство долговечности, если она устойчива к трём типам сбоев: сбоям транзакций, системным сбоям и сбоям носителей информации. Такие прерывания могут возникать на уровне транзакций из-за ошибок ввода данных, отмены оператором, истечения времени ожидания или ошибок, специфичных для приложения, например, попытки снять деньги с банковского счёта при недостаточном количестве средств. В частности, механизм обеспечения надёжности требует примитивов, которые явно указывают начало, завершение и откат транзакций, либо ведение журнала и блокировки. Причина выбора между использованием энергозависимого хранилища, подверженного таким сбоям, и энергонезависимого хранилища заключается в различиях в производительности существующих технологий, используемых для реализации этих типов хранилищ. Однако ситуация, вероятно, изменится по мере роста популярности технологий энергонезависимой памяти (NVM). В системах, включающих энергонезависимое хранилище, долговечность может быть достигнута путём ведения и сброса в энергонезависимое хранилище неизменяемого последовательного журнала транзакций перед подтверждением их завершения. Благодаря свойству атомарности, транзакции можно рассматривать как единицу работы в процессе восстановления, который гарантирует долговечность при использовании журнала. В частности, механизм ведения журнала называется протоколом записи вперёд (WAL) и обеспечивает долговечность, буферизируя изменения на диске перед их синхронизацией с оперативной памятью. Таким образом, путём восстановления из файла журнала все завершённые транзакции устойчивы к системным сбоям, поскольку их можно повторно выполнить. Незавершённые транзакции, напротив, могут быть восстановлены, поскольку их операции записываются в энергонезависимое хранилище до того, как они фактически изменят состояние базы данных. Таким образом, частично выполненные операции можно отменить, не затрагивая состояние системы. После этого незавершённые транзакции могут быть повторно выполнены. Следовательно, журнал транзакций из энергонезависимого хранилища может быть повторно обработан для воссоздания состояния системы непосредственно перед любым последующим системным сбоем. Стоит отметить, что ведение журнала осуществляется как комбинация отслеживания данных и операций (то есть транзакций) в целях повышения производительности.
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, 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. Formally, a database system ensures the durability property if it tolerates three types of failures: transaction, system, and media failures. 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. Specifically, a reliability mechanism requires primitives that explicitly state the beginning, the end, and the rollback of transactions, or logging and locking. 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. However, the situation is likely to evolve as the popularity of non volatile memories (NVM) technologies grows. 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. 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.
Уровень СМИ
На уровне носителей сценарии отказа влияют на энергонезависимые хранилища, такие как жесткие диски, твердотельные накопители и другие типы аппаратных компонентов хранения. На этом уровне существует тесная взаимосвязь между надежностью и восстановлением системы и данных, поскольку основная цель – сохранение данных, не только в онлайн-репликах, но и в виде автономных копий. Следовательно, в случае отказа носителя, надежность транзакций гарантируется возможностью восстановления состояния базы данных из журналов, хранящихся в постоянной памяти, независимо от способа их реализации в системе управления базами данных.
At media level, failure scenarios affect non volatile storage, like hard disk drives, solid state drives, and other types of storage hardware components. 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. 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.
Распределенные базы данных
В распределенных транзакциях обеспечение долговечности требует дополнительных механизмов для сохранения согласованной последовательности состояний на всех узлах базы данных. Это означает, например, что одного узла недостаточно для принятия решения о завершении транзакции подтверждением (commit). Фактически, ресурсы, используемые в этой транзакции, могут находиться на других узлах, где одновременно выполняются другие транзакции. В противном случае, в случае сбоя, если согласованность не может быть гарантирована, будет невозможно подтвердить безопасное состояние базы данных для восстановления. Поэтому все участвующие узлы должны координироваться перед подтверждением commit. Обычно это осуществляется с помощью двухфазного протокола. Кроме того, в распределенных базах данных протоколы журналирования и восстановления также должны учитывать особенности распределенных сред, такие как взаимоблокировки (deadlocks), которые могут препятствовать устойчивости и восстанавливаемости транзакций и, следовательно, долговечности. Широко используемым семейством алгоритмов, обеспечивающих эти свойства, является ARIES (Algorithms for Recovery and Isolation Exploiting Semantics).
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. In fact, 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. 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).