Сеансы зеркального отображения базы данных

Изменения: 14 апреля 2006 г.

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

После подготовки зеркальной базы данных и настройки экземпляров серверов владелец базы данных может начать зеркальное отображение базы данных. Сразу же после начала зеркального отображения каждый участник приступает к регистрации в своей базе данных сведений о состоянии этой базы данных, о другом участнике и о следящем сервере, при наличии такового. Регистрация этих сведений позволяет экземплярам сервера поддерживать продолжительную связь, называемую сеансом зеркального отображения базы данных. На всем протяжении сеанса зеркального отображения базы данных экземпляры сервера контролируют друг друга. Регистрация сведений о состоянии продолжается до тех пор, пока владелец базы данных не остановит сеанс. Дополнительные сведения см. в разделах Состояния зеркального отображения и Контроль состояния зеркального отображения базы данных.

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

Зеркальный сервер немедленно записывает поступающий журнал на диск, где журнал удерживается до применения к зеркальной базе данных. Журнал, хранящийся на диске зеркала, называется очередь повторов. Объем невосстановленного журнала, ожидающего в очереди повторов, является признаком времени, требуемого для переключения на зеркальную базу данных. Дополнительные сведения см. в разделе Оценка прерывания обслуживания во время переключения ролей.

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

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

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

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

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

Параллельные сеансы

Указанный экземпляр сервера может участвовать в нескольких одновременных сеансах зеркального отображения базы данных (по одному на каждую зеркальную базу данных) с теми же или другими экземплярами сервера. Часто экземпляр сервера служит исключительно в качестве участника или следящего сервера во всех сеансах зеркального отображения своей базы данных. Но поскольку каждый сеанс не зависит от остальных сеансов, экземпляр сервера может действовать в некоторых сеансах в качестве участника и в качестве следящего сервера в прочих сеансах. Например, рассмотрим следующие четыре сеанса среди трех экземпляров сервера (SSInstance_1, SSInstance_2 и SSInstance_3). Каждый экземпляр сервера служит в качестве участника в одних сеансах и в качестве следящего сервера в остальных.

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

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

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

При настройке экземпляра сервера для работы одновременно в качестве участника и следящего сервера убедитесь в том, что конечная точка зеркального отображения базы данных поддерживает обе роли (дополнительные сведения см. в разделе Конечная точка зеркального отображения базы данных). Также убедитесь в том, что система обладает достаточными ресурсами для уменьшения вероятности конфликтных ситуаций.

Примечание.
Зеркальные базы данных независимы друг от друга, поэтому эти базы данных не могут переключаться при сбое как единая группа.

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

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

Создание зеркальной базы данных требует, как минимум, создания полной резервной копии основной базы данных и одной последующей резервной копии журнала и восстановления обоих копий в экземпляре зеркального сервера, с использованием предложения WITH NORECOVERY. Кроме того, перед началом зеркального отображения, если сделаны какие-либо дополнительные резервные копии журнала после необходимой резервной копии журнала, необходимо также вручную использовать каждую дополнительную резервную копию журнала (всегда используя WITH NORECOVERY). После использования самой последней резервной копии журнала можно начать зеркальное отображение. Дополнительные сведения см. в разделе Подготовка зеркальной базы данных к зеркальному отображению.

Влияние приостановки сеанса на копию журнала транзакций участника

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

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

Клиентские соединения

Поддержка клиентских соединений для сеансов зеркального отображения базы данных предоставлена поставщиком данных Microsoft .NET для SQL Server. Дополнительные сведения см. в разделе Клиентские соединения с зеркальной базой данных.

См. также

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

Асинхронное зеркальное отображение баз данных (режим высокой производительности)
Состояния зеркального отображения
Обзор зеркального отображения базы данных
Кворум: как следящий сервер влияет на доступность базы данных
Синхронное зеркальное отображение базы данных (режим высокой безопасности)

Другие ресурсы

Контроль состояния зеркального отображения базы данных
Настройка зеркального отображения базы данных

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

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

Журнал изменений