Переключение ролей во время сеанса зеркального отображения базы данных (SQL Server)

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

Замечание

В этом разделе предполагается, что вы знакомы с режимами работы зеркального отображения базы данных. Дополнительные сведения см. в статье Database Mirroring Operating Modes.

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

Это важно

После переключения ролей задания, запущенные в бывшей основной базе данных, должны быть повторно созданы на новом основном сервере для запуска там. Дополнительные сведения см. в разделе "Управление именами входа и заданиями после переключения ролей" (SQL Server).

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

Замечание

Если вы не знакомы с этими режимами работы, ознакомьтесь с режимами работы зеркального отображения базы данных.

• Ручное переключение при отказе

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

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

• Автоматическое переключение

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

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

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

  Замечание

  Рекомендуется задать для свойства WITNESS значение OFF в режиме высокой производительности. В противном случае для подключения базы данных к сети зеркальный сервер должен подключиться к свидетелю.

  Дополнительные сведения см. в разделе "Принудительное обслуживание" (с возможной потерей данных) далее в этом разделе.

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

	Высокая производительность	Режим высокой безопасности без свидетеля	Режим высокой безопасности с свидетелем
автоматическое переключение на резервный режим	нет	нет	Да
Ручное аварийное переключение	нет	Да	Да
Принудительное обслуживание	Да	Да	нет

После переключения роли определенные метаданные должны существовать в обоих партнерах, чтобы все пользователи базы данных могли получить доступ к новой основной базе данных. Кроме того, задания резервного копирования должны создаваться на новом основном сервере, чтобы гарантировать, что база данных продолжает резервироваться по регулярному расписанию. Дополнительные сведения см. в разделе "Управление именами входа и заданиями после переключения ролей" (SQL Server).

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

Отработка отказа вручную

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

Поддержание доступности во время обновлений

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

Замечание

Зеркальное отображение базы данных должно иметь возможность последовательного обновления, но это не гарантируется, так как будущие изменения неизвестны. Дополнительные сведения см. в статье "Минимизация простоя зеркальных баз данных при обновлении экземпляров сервера".

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

Условия, необходимые для ручного переключения

Ручное переключение требует, чтобы безопасность транзакций была задана как ПОЛНАЯ (то есть высокий режим безопасности). Когда партнеры подключены и база данных уже синхронизирована, поддерживается ручное переключение на резерв.

Как работает ручное переключение системы в случае отказа

Ручной переход на резерв инициирует следующую последовательность действий:

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

2. Зеркальный сервер записывает номер последовательности журнала (LSN) последней записи журнала, полученной от основного сервера, в качестве LSN переключения.

   Замечание

   Чтобы просмотреть этот LSN, выберите столбец mirroring_failover_lsn из sys.database_mirroring (Transact-SQL).

3. Если какой-либо журнал ожидает в очереди повторных операций, зеркальный сервер завершает обновление зеркальной базы данных. Количество времени, необходимого для выполнения, зависит от скорости системы, последней рабочей загрузки и объема журнала в очереди переупорядочивания. Для синхронного режима работы время отработки отказа можно регулировать путем ограничения размера очереди повтора. Тем не менее, это может привести к замедлению основного сервера, чтобы позволить зеркального сервера продолжать работу.

   Замечание

   Чтобы узнать текущий размер очереди повтора, используйте счетчик производительности очереди Redo в объекте производительности зеркального отображения базы данных (дополнительные сведения см. в разделе "Мониторинг зеркального отображения базы данных" (SQL Server)).

4. Зеркальный сервер становится новым основным сервером, а бывший основной сервер становится новым зеркальным сервером.

5. Новый основной сервер откатывает все незафиксированные транзакции и переводит свою копию базы данных в онлайн-режим в качестве основной базы данных.

6. Бывший директор принимает роль зеркала, а бывшая основная база данных становится зеркальной базой данных. Новый зеркальный сервер быстро синхронизирует новую зеркальную базу данных с новой основной базой данных.

   Замечание

   Как только новый зеркальный сервер повторно синхронизировал базы данных, отработка отказа снова возможна, но в обратном направлении.

После отработки сбоя клиенты должны повторно подключиться к текущей основной базе данных. Дополнительные сведения см. в разделе "Подключение клиентов к сеансу зеркального отображения базы данных" (SQL Server).

Инициализация ручного переключения

• Ошибочная отработка вручную сеанса зеркалирования баз данных (SQL Server Management Studio)

• Ручное аварийное переключение сеанса зеркального отображения базы данных (Transact-SQL).

Автоматическое переключение на резервное устройство

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

Это важно

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

Условия, необходимые для автоматического переключения на резервный сервер

Для автоматического отказоустойчивого перехода требуются следующие условия:

• Сеанс зеркального отображения базы данных должен работать в режиме высокой безопасности и должен иметь свидетеля. Дополнительные сведения см. в статье Database Mirroring Operating Modes.

• Зеркальная база данных уже должна быть синхронизирована. Это гарантирует, что все журналы, отправленные на зеркальный сервер, были записаны на диск.

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

  Замечание

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

• Зеркальный сервер обнаружил потерю основного сервера.

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

Как работает автоматическое переключение при отказе

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

1. Если основной сервер по-прежнему запущен, он изменяет состояние основной базы данных на DISCONNECTED и отключает все клиенты от основной базы данных.

2. Сервер свидетель и зеркальные серверы регистрируют, что основной сервер недоступен.

3. Если какой-либо журнал ожидает в очереди на повторный ввод, зеркальный сервер завершает перенос вперёд зеркальной базы данных.

   Замечание

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

4. Бывшая зеркальная база данных перемещается в режим "в сети" в качестве новой основной базы данных, а восстановление очищает все незафиксированные транзакции, откатив их как можно быстрее. Блокировки изолируют эти транзакции.

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

На следующем рисунке показан один случай автоматического переключения при сбое.

Изначально все три сервера подключены (сеанс имеет полный кворум). Partner_A является основным сервером и Partner_B является зеркальным сервером. Partner_A (или основная база данных на Partner_A) становится недоступной. Свидетель и Partner_B оба признают, что основной участник больше недоступен, но сеанс сохраняет кворум. Partner_B становится основным сервером и делает ее копию базы данных доступной в качестве новой основной базы данных. В конечном итоге Partner_A повторно подключается к сеансу и обнаруживает, что Partner_B теперь владеет основной ролью. Partner_A затем принимает роль зеркального отображения.

После отработки отказа клиенты должны повторно подключиться к текущей основной базе данных. Дополнительные сведения см. в разделе "Подключение клиентов к сеансу зеркального отображения базы данных" (SQL Server).

Замечание

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

Отключение автоматической отработки отказа (СРЕДА SQL Server Management Studio)

Откройте страницу Database PropertiesMirroring и измените режим работы, выбрав один из следующих параметров:

• Высокая безопасность без автоматического переключения при отказе (синхронная)

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

• Высокая производительность (асинхронная)

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

Отключение автоматической отработки отказа (использование Transact-SQL)

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

Выключение свидетеля

• Удаление свидетеля из сеанса зеркального отображения базы данных (SQL Server)

  Замечание

  Отключение свидетеля при сохранении полной безопасности транзакций помещает сеанс в режим высокой безопасности без автоматической отработки отказа.

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

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

Поддержка принудительной службы зависит от режима работы и состояния сеанса, как показано ниже.

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

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

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

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

Это важно

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

Типичный случай принудительной службы

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

На рисунке исходный основной сервер , Partner_A, становится недоступным для зеркального сервера, Partner_B, что приводит к отключению зеркальной базы данных. Убедившись, что Partner_A недоступен для клиентов, администратор базы данных принудительно запускает сервис с возможной потерей данных на Partner_B. Partner_B становится основным сервером и работает с базой данных в открытом виде (то есть без зеркалирования). На этом этапе клиенты могут повторно подключаться к Partner_B.

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

Замечание

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

Риски принудительной службы

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

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

Последствия принудительного оказания услуги зависят, в частности, от того, имеется ли у сессии свидетель.

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

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

Дополнительные сведения см. в разделе "Управление потенциальной потерей данных" далее в этом разделе.

Управление потенциальной потерей данных

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

Исходный основной сервер пересоединился

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

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

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

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

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

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

Исходный основной сервер не был повторно подключен

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

• Если потенциальная потеря данных допустима

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

• Если потеря данных неприемлема

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

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

Связанные задачи для управления принудительным переключением отказоустойчивости

Принудительно включить службу

• Принудительное выполнение службы в сеансе зеркального отображения базы данных (Transact-SQL).

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

• Приостановка или возобновление сеанса зеркального отображения базы данных (SQL Server)

Создание зеркальной базы данных

Подготовка зеркальной базы данных для зеркального отображения (SQL Server)

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

• Настройка зеркального отображения базы данных (SQL Server)

• Установка сеанса зеркального отображения базы данных с помощью проверки подлинности Windows (SQL Server Management Studio)

См. также

Оценка прерывания работы службы во время переключения ролей (зеркальное отображение базы данных)
Возможные сбои во время зеркального отображения базы данных
Подключение клиентов к сеансу зеркального отображения базы данных (SQL Server)
Свидетель зеркального отображения базы данных
Полное восстановление базы данных (модель полного восстановления)
Режимы работы зеркального отображения базы данных
Состояния зеркального отображения (SQL Server)