Мифы для DBA: незавершённые транзакции продолжаются после отработки отказа

Автор: Paul Randal, A SQL Server DBA myth a day: (1/30) in-flight transactions continue after a failover

Миф: После отработки отказа любые незавершённые транзакции продолжаются.

ЛОЖЬ

Каждый раз, когда происходит отработка отказа, должно произойти какое-то восстановление после сбоя. Если транзакция не была зафиксирована на сервере, к которому было подключение, когда сервер/база данных перестал работать, нет способа, чтобы SQL Server автоматически воссоздал весь контекст транзакции и восстановил незавершённую транзакцию на сервере, принимающем отказ — независимо от того, использовалась ли для отработки отказа кластеризация, зеркалирование, доставка журналов или репликация SAN.

• Для отказоустойчивого кластера, когда происходит отработка отказа, экземпляр SQL перезапускается на другом узле кластера. Все базы данных проходят восстановление после сбоя — которое откатит все незафиксированные транзакции. (См. мою статью в TechNet Magazine за февраль 2009 года с объяснением восстановления после сбоя и того, как оно работает: Ведение журнала и восстановление в SQL Server.)
• Для зеркалирования баз данных журнал транзакций в зеркальной базе данных постоянно используется для выполнения операций повторного выполнения (для записей журнала, поступающих с основного сервера). Когда зеркало переключается на роль основного, журнал транзакций переходит в режим восстановления после сбоя и восстанавливает базу данных, как если бы произошёл сбой — а затем разрешает подключения к базе данных.
• Для доставки журналов резервные копии журнала транзакций периодически применяются к вторичным базам данных доставки журналов. Когда происходит сбой на основном сервере, администратор базы данных переводит вторичную базу данных доставки журналов в оперативный режим, завершая последовательность восстановления (либо немедленно переводя базу данных в оперативный режим, либо применяя все возможные резервные копии журнала транзакций, чтобы привести базу данных в максимально актуальное состояние). Финальная часть любой последовательности восстановления — выполнение фазы отката восстановления после сбоя — откат любых незафиксированных транзакций.
• При репликации SAN операции ввода-вывода на локальный SAN передаются на удалённый SAN для повторного выполнения. Когда происходит сбой, система, подключённая к удалённому SAN, становится оперативной, и базы данных проходят восстановление после сбоя точно так же, как и при отказоустойчивой кластеризации (это чрезмерно упрощённое объяснение — но вы понимаете идею).

Единственная технология, которая позволяет сохранять непрерывные подключения к базе данных при сбое, — это использование виртуализации с функцией живой миграции, когда виртуальная машина запускается, и подключения не знают, что они общаются с другим физическим хост-сервером виртуальной машины.

Но какой бы механизм вы ни использовали — если подключение разрывается, незавершённая транзакция теряется. Поэтому ваше приложение должно быть написано так, чтобы корректно обрабатывать разорванные подключения и предусматривать какой-либо механизм повторной попытки выполнения транзакции.