Маркетинговый ажиотаж вокруг зеркалирования баз данных утверждает, что оно обеспечивает мгновенное обнаружение сбоев и мгновенный переход на резервный сервер.
Это не так. Скорость обнаружения сбоя зависит, среди прочего, от того, что именно вышло из строя.
Этот миф довольно однозначен — зеркальное отображение баз данных позволяет создавать только одно зеркало для каждой основной базы данных. Если вам нужно несколько копий основной базы данных, рассмотрите возможность использования доставки журналов. Вы можете иметь столько вторичных серверов доставки журналов, сколько вам нужно.
Ещё одна классная особенность доставки журналов заключается в том, что для одного из вторичных серверов можно установить задержку применения, скажем, в 8 часов. Это означает, что резервные копии журналов, сделанные на основном сервере (не правда ли забавно, что в разных технологиях используется разная терминология:
Ладно… эта вводная часть как-то сама по себе развилась…) не будут восстановлены на вторичном сервере доставки журналов, пока не пройдёт 8 часов. Если кто-то удалит таблицу в рабочей среде, она почти сразу же исчезнет и в зеркале (с какой-то задержкой, зависящей от состояния очередей SEND и WAIT в тот момент — но вы не можете остановить этот процесс), а вот на вторичном сервере доставки журналов с задержкой применения таблица останется нетронутой.
Кстати, команда SQLCAT написала очень хорошую статью, разоблачающую миф (который происходит из документации Books Online) о том, что можно зеркалировать только 10 баз данных на один экземпляр — см. Mirroring a Large Number of Databases in a Single SQL Server Instance. Также взгляните на статью базы знаний, которую я написал для CSS, где обсуждается то же самое: KB 2001270 Предварительные условия, ограничения и рекомендации по зеркальному отображению базы данных.
Каждый раз, когда происходит отработка отказа, должно произойти какое-то восстановление после сбоя. Если транзакция не была зафиксирована на сервере, к которому было подключение, когда сервер/база данных перестал работать, нет способа, чтобы SQL Server автоматически воссоздал весь контекст транзакции и восстановил незавершённую транзакцию на сервере, принимающем отказ — независимо от того, использовалась ли для отработки отказа кластеризация, зеркалирование, доставка журналов или репликация SAN.
Этот документ помогает диагностировать или решать проблемы, связанные с производительностью репликации.
