Crash recovery¶

Crash recovery (от англ. crash — аварийное завершение, recovery — восстановление) — это процесс восстановления целостности и согласованности данных в компьютерных системах, базах данных, файловых системах и приложениях после внезапного сбоя (аварийного завершения работы, отключения питания, ошибки программного обеспечения или аппаратного отказа). Основная цель crash recovery — вернуть систему в непротиворечивое состояние, минимизировать потерю данных и обеспечить возможность дальнейшей корректной работы.

¶Основные причины сбоев

Сбои, требующие применения механизмов crash recovery, могут быть вызваны различными факторами:

• Аппаратные сбои: отключение электропитания, выход из строя жёсткого диска, сбой оперативной памяти (RAM), ошибки контроллера ввода-вывода.
• Программные ошибки: ошибки в коде операционной системы, драйверов, приложений или систем управления базами данных (СУБД), приводящие к аварийному завершению (segmentation fault, kernel panic, blue screen of death).
• Ошибки среды выполнения: переполнение стека, нехватка памяти, взаимные блокировки (deadlocks), ошибки ввода-вывода.
• Человеческий фактор: случайное нажатие кнопки сброса, неправильное завершение работы системы, удаление критических файлов.
• Внешние воздействия: скачки напряжения, электромагнитные помехи, вибрации, перегрев.

¶Основные принципы и подходы

Механизмы crash recovery опираются на несколько фундаментальных принципов, обеспечивающих надёжность хранения и обработки данных.

¶Атомарность транзакций (Atomicity)

В системах управления базами данных и файловых системах операции часто группируются в транзакции. Атомарность гарантирует, что транзакция либо выполняется полностью (commit), либо не выполняется вовсе (rollback). Если сбой происходит во время выполнения транзакции, crash recovery откатывает все частично выполненные изменения, возвращая систему к состоянию, предшествовавшему началу транзакции. Это предотвращает появление «полузаписанных» данных.

¶Согласованность (Consistency)

После восстановления данные должны соответствовать всем заданным ограничениям (например, внешним ключам, уникальности, проверочным условиям). Crash recovery гарантирует, что система переходит из одного согласованного состояния в другое, минуя промежуточные, потенциально некорректные состояния.

¶Изоляция (Isolation)

В многопользовательских системах crash recovery должна учитывать, что в момент сбоя могли выполняться несколько параллельных транзакций. Восстановление должно либо завершить их все, либо откатить, не допуская смешивания частичных результатов разных транзакций.

¶Долговечность (Durability)

После успешного завершения транзакции (commit) её результаты должны быть сохранены на энергонезависимом носителе и не должны быть потеряны при последующих сбоях. Crash recovery гарантирует, что зафиксированные данные не пропадут.

¶Методы реализации crash recovery

Существуют два основных подхода к реализации crash recovery: откат (rollback) и накат (redo). Чаще всего они применяются совместно в рамках журналирования (logging).

¶Журналирование (Write-Ahead Logging, WAL)

Наиболее распространённый метод, используемый в большинстве современных СУБД (PostgreSQL, SQLite, MySQL с InnoDB) и файловых системах (ext3, ext4, NTFS, ZFS). Принцип заключается в том, что перед внесением изменений в основные структуры данных (например, страницы базы данных или блоки файловой системы) система записывает информацию об этих изменениях в специальный журнал (log). Журнал ведётся последовательно и хранится на энергонезависимом носителе.

Если сбой происходит до того, как изменения были записаны в основное хранилище, при следующем запуске система считывает журнал и выполняет два этапа:

• Redo (накат): повторное применение всех операций, которые были зафиксированы в журнале как завершённые (committed), но ещё не были записаны в основное хранилище. Это гарантирует долговечность.
• Undo (откат): отмена всех операций, которые были начаты, но не были завершены (uncommitted). Это гарантирует атомарность.

Журнал обычно имеет ограниченный размер и циклически перезаписывается (checkpointing). Во время контрольной точки (checkpoint) система гарантирует, что все изменения до определённого момента записаны на диск, и может очистить соответствующую часть журнала.

¶Теневые копии (Shadow Paging)

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

¶Файловые системы с журналированием

Многие современные файловые системы (ext3, ext4, NTFS, HFS+, APFS, XFS, Btrfs) используют crash recovery для предотвращения повреждения метаданных (информации о структуре каталогов, размещении файлов, правах доступа) при сбое. Журнал может содержать только метаданные (журналирование метаданных) или также данные (журналирование данных, что снижает производительность). При сбое файловая система при загрузке автоматически проверяет журнал и восстанавливает целостность метаданных, избегая полной проверки (fsck), которая может занимать много времени на больших томах.

¶Примеры реализации в популярных системах

¶PostgreSQL

PostgreSQL использует Write-Ahead Logging (WAL). Журнал (pg_wal) содержит все изменения, вносимые в базу данных. При аварийном завершении сервер автоматически выполняет восстановление при следующем запуске: считывает WAL, накатывает зафиксированные транзакции и откатывает незавершённые. В режиме синхронной репликации WAL может передаваться на резервные серверы.

¶SQLite

SQLite в режиме по умолчанию (journal mode) использует журнал отката (rollback journal). При сбое он автоматически восстанавливает базу данных из журнала. Начиная с версии 3.7.0, поддерживается режим WAL, который обеспечивает более высокую производительность при параллельных чтениях и записях.

¶Microsoft SQL Server

Использует журнал транзакций (transaction log). Crash recovery включает три фазы: анализ (analysis), повтор (redo) и откат (undo). Анализ определяет, какие транзакции были зафиксированы, а какие нет, после чего выполняются соответствующие действия.

¶Linux (ext4)

Файловая система ext4 использует журналирование метаданных. При монтировании после сбоя она автоматически проверяет журнал и восстанавливает структуру каталогов и атрибуты файлов. Данные файлов, не записанные на диск, могут быть потеряны, если не используется режим журналирования данных (data=ordered или data=journal).

¶Ограничения и риски

Несмотря на высокую надёжность, механизмы crash recovery не являются абсолютной защитой:

• Потеря данных: если сбой происходит до записи в журнал, данные могут быть потеряны. Это характерно для кэширования записи на уровне операционной системы или жёсткого диска.
• Повреждение журнала: если журнал физически повреждён (например, из-за дефекта диска), восстановление может быть невозможным или привести к неполному восстановлению.
• Аппаратные сбои: при выходе из строя самого носителя данных (жёсткого диска, SSD) crash recovery на уровне файловой системы или СУБД бесполезно — требуется аппаратное восстановление данных.
• Человеческий фактор: случайное удаление данных или неправильная настройка системы могут сделать crash recovery неэффективным.

¶См. также

• Транзакция (базы данных)
• Журнал транзакций
• Резервное копирование
• Файловая система
• Целостность данных

¶Источники

• Gray, J., Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.
• Silberschatz, A., Korth, H. F., Sudarshan, S. (2010). Database System Concepts (6th ed.). McGraw-Hill.
• PostgreSQL Documentation: Chapter 30. Reliability and the Write-Ahead Log.
• SQLite Documentation: Write-Ahead Logging.
• Microsoft SQL Server Documentation: Transaction Log Architecture and Recovery.
• Linux Kernel Documentation: ext4 Filesystem.