Асинхронное зеркальное отображение баз данных (режим высокой производительности)

Изменения: 5 декабря 2005 г.

Если безопасность транзакций отключена, сеанс зеркального отображения базы данных выполняется в асинхронном режиме. Асинхронные операции поддерживаются только в режиме высокой производительности. В этом режиме производительность повышается за счет высокого уровня доступности. В режиме высокой производительности задействованы только основной сервер и зеркальный сервер. Проблемы, возникающие на зеркальном сервере, никогда не влияют на основной сервер. При потере соединения с основным сервером зеркальная база данных переходит в состояние DISCONNECTED, но остается доступной в режиме «горячего» резервирования.

Режим высокой производительности поддерживает только одну форму переключения ролей: принудительное обслуживание (с возможной потерей данных), при котором зеркальный сервер используется в качестве сервера «горячего» резервирования. Принудительное обслуживание — одна из возможных реакций на ошибку основного сервера. Так как при этом возможна потеря данных, перед переходом в режим вынужденного обслуживания зеркальным сервером следует рассмотреть другие возможности. Дополнительные сведения см. в подраздел «Реакция на ошибку основного сервера» далее в этом разделе.

На следующем рисунке показана конфигурация сеанса в режиме высокой производительности.

В режиме высокой производительности, как только основной сервер отправляет журнал транзакций зеркальному серверу, основной сервер отправляет подтверждение клиенту, не дожидаясь ответа от зеркального сервера. Транзакции фиксируются без ожидания записи журнала на диск на зеркальном сервере. Асинхронный режим позволяет основному серверу работать с минимальной задержкой транзакций.

Зеркальный сервер пытается соответствовать записям в журнале, отправляемым основным сервером. Но зеркальная база данных может отражать предыдущее состояние основной базы данных, однако разрыв между базами данных, как правило, небольшой. Однако этот разрыв может стать существенным, если основной сервер сильно загружен или перегружена система зеркального сервера.

Когда рекомендуется использовать режим высокой производительности?

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

Примечание.

Доставка журналов может дополнять зеркальное отображение базы данных и является подходящей альтернативой для асинхронного зеркального отображения базы данных. Дополнительные сведения о преимуществах применения доставки журналов см. в разделе Настройка высокого уровня доступности. Сведения об использовании доставки журналов совместно с зеркальным отображением баз данных см. в разделе Зеркальное отображение баз данных и доставка журналов.

Влияние следящего сервера на высокопроизводительный режим

При использовании Transact-SQL для настройки высокопроизводительного режима, если для параметра SAFETY установлено значение OFF, настоятельно рекомендуется также установить параметр WITNESS в значение OFF. Следящий сервер может использоваться с высокопроизводительным режимом, но это не принесет пользы и представляет риск.

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

Если следящий сервер установлен для сеанса с высокопроизводительным режимом, принудительное исполнение кворума означает, что:

• если соединение с зеркальным сервером теряется, основной сервер должен быть подключен к следящему. В противном случае основной сервер переводит свою базу данных в автономный режим до тех пор, пока следящий или зеркальный сервер не восстановит соединение с сеансом;
• если потеряно соединение с основным сервером, для переключения на зеркальный сервер необходимо, чтобы зеркальный сервер был подключен к следящему.

Примечание.
Дополнительные сведения о типах кворума см. в разделе Кворум: как следящий сервер влияет на доступность базы данных.

Реакция на ошибку основного сервера

Если на основном сервере произошла ошибка, у владельца базы данных есть несколько вариантов действия:

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

  Примечание.
  Если создать резервную копию заключительного фрагмента журнала не удается и нельзя ждать восстановления основного сервера, можно воспользоваться режимом вынужденного обслуживания, преимущество которого в продолжении сеанса в текущем состоянии.

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

См. также

Основные понятия

Принудительное обслуживание (с вероятностью потери данных)
Синхронное зеркальное отображение базы данных (режим высокой безопасности)
Настройки Transact-SQL и режимы зеркального отображения базы данных
Основные сведения об отправке журналов

Справка и поддержка

Получение помощи по SQL Server 2005