Миф: Переход на зеркальный сервер при зеркалировании баз данных происходит мгновенно

Автор: Paul Randal, A SQL Server DBA myth a day: (11/30) database mirroring failover is instantaneous;

Переход на реплику при зеркальном отображении баз данных происходит мгновенно

ЛОЖЬ

Переход на зеркальный сервер (failover) может происходить автоматически или быть инициирован вручную.

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

Ручной переход выполняете вы — либо потому, что сервер-свидетель отсутствовал (и, следовательно, зеркальный сервер никогда не сможет сформировать кворум, необходимый для автоматического перехода), либо потому, что состояние сеанса зеркалирования на момент выхода из строя основного сервера было отличным от SYNCHRONIZED.

После инициирования перехода зеркальная база данных не станет доступной в роли основной до тех пор, пока не будет обработана очередь REDO. Очередь REDO — это набор записей журнала, которые были получены на зеркальном сервере от основного, но ещё не воспроизведены (не применены) в зеркальной базе данных. Даже при использовании синхронного зеркалирования баз данных транзакция может быть зафиксирована на основном сервере, как только её записи журнала будут записаны на диск журнала зеркального сервера — ей не нужно ждать, пока записи журнала будут фактически применены в зеркальной базе данных. Во время перехода вперёд (roll-forward) зафиксированных транзакций должно быть завершено до того, как зеркальная база данных станет доступной, а откат незафиксированных транзакций происходит уже после того, как база данных станет доступной (с использованием того же механизма, что и быстрое восстановление в Enterprise Edition — см. мою запись в блоге Логирование блокировок и быстрое восстановление).

Воспроизведение (redo) выполняется в однопоточном режиме в Standard Edition, а также в Enterprise Edition на серверах с менее чем 5 ядрами процессора. В Enterprise Edition на серверах с более чем 5 ядрами процессора для каждых 4 ядер процессора выделяется отдельный поток для применения журнала (redo thread).

Примечание переводчика: В современных версиях механизм многопоточного REDO был существенно доработан и улучшен.

Таким образом, вы видите, что время перехода полностью зависит от того, какой объём журнала нужно обработать в очереди REDO, от вычислительной мощности зеркального сервера, а также от того, какие другие рабочие нагрузки могут выполняться на зеркальном сервере и конкурировать за ресурсы.

Из-за распространённого мнения, что зеркалирование всегда обеспечивает быстрый переход, многие не отслеживают очередь REDO на зеркальном сервере. Это очень важно, поскольку объём очереди REDO напрямую коррелирует с продолжительностью простоя, который вы испытаете во время перехода.

Для получения немного более подробной информации обо всём этом см. запись в документации Books Online: Оценка прерывания обслуживания во время переключения ролей (зеркальное отображение базы данных).