Долговечность (системы управления базами данных)

Долговечность в системах управления базами данных — это свойство, относящееся к числу свойств ACID, обеспечивающее, что результаты завершённых транзакций сохраняются навсегда, даже в случае сбоев[1], в том числе аварий и катастрофических событий. Например, если система бронирования авиабилетов сообщила об успешном резервировании места, то оно останется забронированным даже в случае сбоя системы[2].

Формально система баз данных обеспечивает свойство долговечности, если она устойчива к трём типам отказов: транзакционным, системным и медианным (на уровне носителя данных)[1]. В частности, транзакционный сбой происходит, если выполнение транзакции было прервано до завершения всех её операций[3]. Подобные прерывания могут быть вызваны на уровне транзакций ошибками ввода, отменой оператором, тайм-аутом или специфическими ошибками приложения, например, при попытке снять деньги со счёта с недостаточным остатком[1]. На системном уровне сбой возникает в случае потери содержимого оперативной памяти, например, из-за сбоя системы, исчерпания памяти и тому подобных причин[3]. На уровне носителя сбой означает потерю устойчивого хранилища или его части — это могут быть, например, отказы дисков[1]

Таким образом, для обеспечения долговечности система должна реализовывать такие процедуры и механизмы, которые гарантируют сохранение последствий зафиксированных транзакций (даже путём восстановления), тогда как последствия незавершённых (незафиксированных на момент сбоя) транзакций должны быть отменены и не влиять на состояние базы данных. Корректность такого поведения обеспечивается при наличии у транзакций свойств устойчивости и восстанавливаемости.[3].

Механизмы

undefined

В транзакционных системах механизмы обеспечения долговечности тесно связаны с понятием надёжности систем, предложенным Джимом Греем в 1981 году[1] К долговечности также относятся аспекты свойств атомарности и согласованности баз данных.[4]. Надёжный механизм транзакций требует наличия примитивов, явно обозначающих начало, завершение и откат транзакции[1] что также предполагается для других свойств ACID. Далее рассматриваются только те механизмы, которые непосредственно обеспечивают долговечность; их выделяют на уровне транзакций, системы и носителя. Аналогичным образом проектируются сценарии для разных типов сбоев, которые необходимо учитывать при обеспечении долговечности баз данных.[3]

Уровень транзакций

Долговечность при сбоях на уровне транзакций, таких как отменённые запросы или противоречивые действия (например, заблокированные ограничениями или триггерами) перед фиксацией, обеспечивается свойством сериализуемости исполнения транзакций. Состояние, образованное ранее зафиксированными транзакциями, доступно в основной памяти, а изменения незавершённых транзакций могут быть отменены; сериализуемость позволяет отличить их последствия, которые будут отброшены.[3] Кроме того, не рекомендуется использовать изменения «на месте» (in-place), при которых новые значения перезаписывают старые без ведения истории.[1] Существуют различные подходы к фиксации истории изменений, например, решения на основе меток времени[5], или журналирования и блокировок[1]

Уровень системы

На системном уровне сбои возникают,[3] когда содержимое оперативной памяти теряется, например, в случае сбоя или отключения питания. Современные СУБД используют оперативную память (или основную память) по-разному: некоторые полностью хранят в ней данные без гарантий долговечности; другие — часть данных в памяти и часть на энергонезависимом носителе; третьи используют память только для состояния, а все данные держат на диске.[6]. Причина выбора комбинации памяти с различными надёжными и ненадёжными носителями кроется в различиях производительности используемых технологий хранения. Однако эта ситуация может измениться по мере распространения энергонезависимых памяти (NVM)[7].

В системах с энергонезависимым хранением долговечность обеспечивается сохранением и сбросом неизменяемого последовательного журнала транзакций на такой носитель до подтверждения фиксации. Благодаря свойству атомарности, транзакции выступают в качестве единицы восстановления в процессе восстановления при сбоях, используя журнал. Обычно реализуется механизм журналирования с опережающей записью (WAL), который позволяет предварительно размещать изменения на диске до их синхронизации с основной памятью. Восстановление состояния возможно путём повторного применения зафиксированных транзакций из журнала; незавершённые транзакции же могут быть отменены, так как их операции тоже записываются в журнал до изменения базы[8]. Таким образом, частично выполненные операции могут быть отменены, не изменяя целостность системы, а незавершённые транзакции можно повторно запустить после восстановления. Журнал транзакций с энергонезависимого носителя может быть переобработан для воспроизведения состояния системы до любого последующего сбоя[9]. Обычно учитываются как сами данные, так и транзакции/операции для достижения высокой производительности.

Уровень носителя

На уровне носителя сбои затрагивают энергонезависимые хранилища — жёсткие диски, SSD и другие аппаратные компоненты хранения[8]. Для долговечности на этом уровне СУБД опирается на концепцию «устойчивой памяти» (stable memory), то есть памяти, практически не подверженной сбоям. Такое свойство достигается с помощью механизмов репликации и надёжных протоколов записи[4].

Для логической реализации устойчивой памяти применяются технологии вроде зеркалирования дисков (RAID) и другие; их выбор определяется требованиями приложения[4]. Как правило, стратегии репликации и избыточности доступны на разных уровнях технологического стека, что позволяет защититься от потери данных даже в случае аппаратных аварий и повреждений хранилища[10]. На этом уровне долговечность тесно связана с механизмами резервного копирования и восстановления, причём защита данных может обеспечиваться не только в онлайн-репликах, но и офлайн-копиях[4] К таким мерам относятся резервное копирование, программы предотвращения потерь данных и меры аварийного восстановления ИТ-инфраструктуры.[11].

В случае сбоя носителя долговечность достигается способностью восстановить состояние базы данных по журналам и дампам, сохранённым в «устойчивой памяти», независимо от способа реализации[8]. Существуют различные методы хранения и восстановления состояния базы данных, позволяющие повысить эффективность по сравнению с прямым анализом полного журнала: инкрементальные дампы, разностные файлы или контрольные точки[12].

Распределённые базы данных

В распределённых транзакциях обеспечение долговечности требует дополнительных механизмов для согласованного сохранения состояния на всех узлах базы данных. Это означает, что один узел не может принять решение о фиксации транзакции самостоятельно, так как задействованные ресурсы разбросаны по разным компьютерам, где одновременно идут другие операции. Иначе гарантировать устойчивое восстановление состояния базы в случае сбоя окажется невозможно. Поэтому все участвующие узлы должны взаимодействовать перед фиксацией — обычно с помощью двухфазного протокола фиксации[13].

Кроме того, в распределённых системах протоколы журналирования и восстановления должны учитывать особенности распределённой среды, такие как взаимоблокировки, которые могут препятствовать устойчивости и восстановлению транзакций, а следовательно, и долговечности[13]. Одна из наиболее распространённых семейство алгоритмов, обеспечивающих эти свойства — алгоритмы восстановления и изоляции с использованием семантики (ARIES)[8].

Примечания

  1. 1 2 3 4 5 6 7 8 Gray, Jim (1981). “The transaction concept: Virtues and limitations” (PDF). VLDB [англ.]. 81: 144—154. Дата обращения 2024-06-20.
  2. ACID Compliance: What It Means and Why You Should Care (англ.). MariaDB (29 июля 2018). Дата обращения: 20 июня 2024.
  3. 1 2 3 4 5 6 Hadzilacos, Vassos (1988). “A theory of reliability in database systems”. Journal of the ACM [англ.]. 35 (1): 121—145. DOI:10.1145/42267.42272. ISSN 0004-5411. S2CID 7052304. Дата обращения 2024-06-20. |access-date= требует |url= (справка)
  4. 1 2 3 4 Database systems: concepts, languages & architectures : [англ.]. — New York : McGraw-Hill, 1999. — P. 311–320. — ISBN 978-0-07-709500-0.
  5. Svobodova, L. (1980). “MANAGEMENT OF OBJECT HISTORIES IN THE SWALLOW REPOSITORY”. Mit/LCS Tr-243 [англ.]. USA. Дата обращения 2024-06-20.
  6. Petrov, Oleksandr. Database internals: a deep dive into how distributed data systems work : [англ.]. — 1st. — Beijing Boston Farnham Sebastopol Tokyo : O'Reilly, 2019. — P. 40–42. — ISBN 978-1-4920-4034-7.
  7. Arulraj, Joy. How to Build a Non-Volatile Memory Database Management System // Proceedings of the 2017 ACM International Conference on Management of Data : [англ.] / Joy Arulraj, Andrew Pavlo. — New York, NY, USA : Association for Computing Machinery, 9 мая 2017. — P. 1753–1758. — ISBN 978-1-4503-4197-4. — doi:10.1145/3035918.3054780.
  8. 1 2 3 4 Petrov, Oleksandr. Database internals: a deep dive into how distributed data systems work : [англ.]. — 1st. — Beijing Boston Farnham Sebastopol Tokyo : O'Reilly, 2019. — P. 185–195. — ISBN 978-1-4920-4034-7.
  9. Mohan, C.; Haderle, Don; Lindsay, Bruce; Pirahesh, Hamid; Schwarz, Peter (1 марта 1992). “ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging”. ACM Transactions on Database Systems [англ.]. 17 (1): 94—162. DOI:10.1145/128765.128770. ISSN 0362-5915. S2CID 8759704. Дата обращения 2024-06-20. |access-date= требует |url= (справка)
  10. Eich, Margaret H. A classification and comparison of main memory database recovery techniques // 1987 IEEE Third International Conference on Data Engineering : [англ.]. — IEEE, 1 февраля 1987. — P. 332–339. — ISBN 978-0-8186-0762-2. — doi:10.1109/ICDE.1987.7272398.
  11. Choy, Manhoi; Leong, Hong Va; Wong, Man Hon (2000). “Disaster recovery techniques for database systems”. Communications of the ACM [англ.]. 43 (11es): 6. DOI:10.1145/352515.352521. ISSN 0001-0782. S2CID 14781378. Дата обращения 2024-06-20.
  12. Verhofstad, Joost S. M. (1 июня 1978). “Recovery Techniques for Database Systems”. ACM Computing Surveys [англ.]. 10 (2): 167—195. DOI:10.1145/356725.356730. S2CID 8847522. Дата обращения 2024-06-20.
  13. 1 2 Mohan, C.; Haderle, Don; Lindsay, Bruce; Pirahesh, Hamid; Schwarz, Peter (1 марта 1992). “ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging”. ACM Transactions on Database Systems [англ.]. 17 (1): 94—162. DOI:10.1145/128765.128770. ISSN 0362-5915. S2CID 8759704. Дата обращения 2024-06-20. |access-date= требует |url= (справка)

Литература

  • Campbell, Laine. Database Reliability Engineering : [англ.] / Laine Campbell, Charity Majors. — O'Reilly Media, Inc., 2017. — ISBN 9781491926215.
  • Taylor, C.A. A case study in database reliability: Component types, usage profiles, and testing // Proceedings of the 1st international workshop on Testing database systems : [англ.] / C.A. Taylor, M.S. Gittens, A.V. Miranskyy. — июнь 2008. — P. 1–6. — ISBN 9781605582337. — doi:10.1145/1385269.1385283.

Категории