Сразу заметим, что зеркалирование не является единственной технологией, которая применяется для повышенной отказоустойчивости. Существует ещё и публикация журнала транзакций (логшипинг) а также репликация, но не каждая БД может поддерживать репликацию, а логшипинг требует публикацию журнала транзакций на общем ресурсе, что далеко не всегда приемлимо. У зеркального отображения тоже есть свои ограничения, например нельзя зеркалировать служебные БД master, msdb, tempdb или model, но так уж ли они нужны? Достаточно копии master.
К преимуществам зеркального отображения относятся:
- защита данных:
- повышенная доступность данных;
- не требуются общие диски;
- оборудование серверов-партнеров может различаться;
- доступность при обновлениях
Терминология зеркального отображения.
Основной сервер (Principal) - рабочий сервер-источник, на котором размещается база данных, которая отправляет свои журналы транзакций зеркальному серверу и его базе данных.
Зеркальный сервер(Mirror) - сервер-получатель, на котором размещается резервная копия базы данных. Зеркальная копия постоянно синхронизируется с базой данных основного сервера.
Следящий сервер(Witness) - сервер, который наблюдает за работой основного и зеркального серверов, и может запустить процесс автоматического перехода на другой ресурс при сбое (поменять роли основного и зеркального сервера). Следящий сервер является необязательным компонентом и может отсутствовать.
Как работает зеркальное отображение.
Оснойной сервер обслуживает запросы пользователей и отправляет журнал транзакций зеркальному серверу. Т.е. зеркальный сервер повторяет все операции вставки, обновления и удаления, как и в основной базе. Как только зеркальный сервер выполняет и фиксирует транзакции, он отправляет основному подтверждающее сообщение. В режиме высокого уровня безопасности новые транзакции основным сервером исполнятся не будут, до получения подтверждения от зеркального. Это напоминает идущие рядом автомобили, причем если один начинает отставать, второй тоже сбрасывает скорость. Медленно, но надежно. При сбое на основном сервере необходимо переключиться на зеркальный вручную (по сути поменять роли основной-зеркальный). Режим высокого уровня доступности похож на описанный выше, за исключением того, что переключение происходит автоматически, доступность серверов контролирует следящий сервер. Как только выходит из строя основной сервер, следящий меняет их ролями с зеркальным, когда восстановится основной, произойдет обратная замена.
В противовес описанному, режим высокой производительности (ещё называют асинхронный) позволяет основному серверу исполнять транзакции, не дожидаясь подтверждения от зеркального. Т.е. нарушается, так называемая, транзакционная безопасность. Особенно это подходит, когда зеркальный обладает менее мощными аппаратными ресурсами. Т.е. один из атвомобилей вырывается вперед, второй старается его догнать. Этот режим не требует наличия следящего сервера.
Действия после сбоя.
Предположим, что в результате сбоя пропал зеркальный сервер, в таком случае основной продолжает обслуживать пользовательские подключения. После восстановления зеркального, резервная база автоматически подключится и догонит рабочую.
Если разрушена центральная база, необходимо выполнить принудительное восстановление:
ALTER DATABASE MIRROR_TEST SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
Часть данных может потеряться (не успели попасть в зеркало), но тут придется мириться. После принудительного восстановления зеркальная база становится основной, а основная - зеркальной. Чтобы запустить зеркалирование, на новой зеркальной выполняем команду:
ALTER DATABASE MIRROR_TEST SET PARTNER RESUME
Чтобы просто поменяться ролями выполняем:
ALTER DATABASE MIRROR_TEST SET PARTNER FAILOVER
В итоге основной становится зеркальным, зеркальный - основным.