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

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

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

• Полный кворум включает как партнеров, так и свидетеля.

• Кворум свидетеля и партнера состоит из свидетеля и любого партнера.

• Кворум между партнерами состоит из двух партнеров.

На следующем рисунке показаны эти типы кворума.

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

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

Кворум в сеансах режима High-Safety

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

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

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

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

• Кворум "свидетель-партнер", состоящий из свидетеля и любого партнера.

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

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

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

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

    В этом случае происходит автоматическое переключение. Дополнительные сведения см. в статье Database Mirroring Operating Modes.

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

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

• Кворум партнеров, состоящий из двух партнеров.

  Пока партнеры сохраняют кворум, база данных остается в СИНХРОНИЗИРОВАННОМ состоянии, и возможность ручного переключения остается. Без следящего сервера автоматическая отработка отказа невозможна; но когда свидетель восстанавливает кворум, сеанс возобновляет обычную операцию, а автоматическая отработка отказа снова поддерживается.

• Сеанс теряет кворум.

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

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

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

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

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

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

Сценарий 1 показывает, как после сбоя исходного основного сервера (Partner_A) свидетель и зеркало согласны с тем, что субъект, Partner_A, больше недоступен и кворум формы. Затем зеркальное отображение Partner_B предполагает роль субъекта. Выполняется автоматическая отработка отказа, и Partner_B приводит свою копию базы данных в активный режим. Затем Partner_B идет вниз, и база данных переходит в автономный режим. Позже бывший основной сервер Partner_A повторно подключается к свидетелю, восстанавливая кворум, но при взаимодействии с ним Partner_A узнает, что не может привести свою копию базы данных в рабочее состояние, так как Partner_B теперь занимает основную роль. Когда Partner_B повторно присоединиться к сеансу, он возвращает базу данных в режим "в сети".

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

См. также

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