Миф: Зеркалирование баз данных мгновенно обнаруживает сбои

Автор: Paul Randal, A SQL Server DBA myth a day: (10/30) database mirroring detects failures immediately

Database Mirroring мгновенно обнаруживает сбои

ЛОЖЬ

Маркетинговый ажиотаж вокруг зеркалирования баз данных утверждает, что оно обеспечивает мгновенное обнаружение сбоев и мгновенный переход на резервный сервер.

Это не так. Скорость обнаружения сбоя зависит, среди прочего, от того, что именно вышло из строя.

Самое быстрое обнаружение сбоя происходит, когда экземпляр SQL Server на основном сервере завершает работу/аварийно завершается. Когда зеркальный сервер отправляет свой периодический запрос (ping) раз в секунду, операционная система на основном сервере поймёт, что на TCP-порту, по которому стучится зеркальный сервер, нет слушающего процесса, и даст об этом знать зеркальному серверу. Это занимает не более одной секунды.

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

Следующий по скорости пример — недоступность диска с журналом транзакций. SQL Server будет продолжать отправлять запросы на запись в подсистему ввода-вывода, через 20 секунд без завершения операции ввода-вывода начнёт жаловаться в журнале ошибок и, наконец, через 40 секунд объявит диск с журналом недоступным. База данных переводится в режим «offline», и объявляется сбой зеркалирования. SQL Server, видите ли, очень терпелив — например, с блокировками он будет спокойно ждать вечно, если только не обнаружит взаимоблокировку.

Повреждение страницы может вообще не спровоцировать сбой. Если обычный запрос получает ошибку 823 или 824, зеркалированию всё равно (хотя в версии 2008 оно попытается их исправить (с некоторыми оговорками) — см. SQL Server 2008: Automatic Page Repair with Database Mirroring). Однако если откат транзакции наткнётся на ошибку 823 или 824, база данных немедленно становится подозрительной (suspect), так как теряет транзакционную согласованность -> сбой зеркалирования.

Мораль истории такова: не верьте всему, что написано в рекламных брошюрах :-)