Кворум: как следящий сервер влияет на доступность базы данных
Когда для сеанса зеркального отображения базы данных назначен следящий сервер, обязательно наличие кворума. Кворум — это связь, возникающая, когда два или несколько экземпляров сервера в сеансе зеркального отображения подключаются друг к другу. Обычно кворум включает три соединенных друг с другом экземпляра сервера. Если указан следящий сервер, то кворум необходим, чтобы сделать базу данных доступной. Кворум, рассчитанный на режим высокого уровня безопасности с автоматическим переходом на другой ресурс, гарантирует, что в любой момент времени база данных принадлежит только одному участнику.
Если экземпляр сервера отключается от сеанса зеркального отображения, экземпляр теряет кворум. Если не подключено ни одного экземпляра сервера, сеанс теряет кворум и база данных выходит из оперативного режима. Возможны три типа кворума.
Полный кворум состоит из обоих участников и следящего сервера.
Кворум «следящий сервер-участник» состоит из следящего сервера и одного из участников.
Кворум «участник-участник» состоит из двух участников.
На следующем рисунке показаны все три типы кворума.
.gif "Кворумы: полный; следящего и одного участника; обоих участников")
Пока текущий основной сервер имеет кворум, он играет роль основного и продолжает обслуживать базу данных, пока владелец базы данных не произведет переход на другой ресурс вручную. Если основной сервер теряет кворум, он перестает обслуживать базу данных. Автоматический переход на другой ресурс может произойти только в том случае, если основная база данных утратила кворум, что является гарантией того, что обслуживание базы данных прекращено.
Отключенный экземпляр сервера сохраняет свою последнюю роль в сеансе. Как правило, в определенный момент времени отключенный экземпляр сервера производит повторное подключение к сеансу и восстанавливает кворум.
.gif "Важное примечание") Важно! |
|---|
Следящий сервер следует устанавливать только в том случае, когда предполагается использовать режим высокого уровня безопасности с автоматическим переходом на другой ресурс. В режиме высокой производительности, для которого следящий сервер не нужен, настоятельно рекомендуется установить WITNESS в значение OFF. Дополнительные сведения о влиянии следящего сервера на доступность базы данных для сеанса в режиме высокой производительности см. в разделе Асинхронное зеркальное отображение баз данных (режим высокой производительности). |
Кворум в сеансах с режимом высокого уровня безопасности
В режиме высокого уровня безопасности кворум обеспечивает автоматический переход на другой ресурс благодаря наличию контекста, по которому находящиеся в кворуме экземпляры серверов определяют, какой из участников играет роль основного. Основной сервер обслуживает базу данных, если она имеет кворум. Если основной сервер теряет кворум, а синхронизированный зеркальный и следящий серверы сохраняют его, то выполняется автоматический переход на другой ресурс.
В сеансах с режимом высокого уровня безопасности существуют следующие сценарии кворума.
Полный кворум состоит из участников и следящего сервера.
Обычно в трехстороннем кворуме участвуют все три экземпляра серверов, что называется полным кворумом. При полном кворуме основной и зеркальный сервера продолжают играть соответствующие роли (пока не произойдет переход на другой ресурс вручную).
Кворум «следящий сервер-участник» состоит из следящего сервера и одного из участников.
Если вследствие выхода из строя одного из участников зеркального отображения произойдет разрыв сетевого соединения, возможны два варианта развития событий.
Соединение с зеркальным сервером теряется, а основной и следящий серверы удерживают кворум.
В этом случае основной сервер устанавливает свою базу данных в режим DISCONNECTED и работает с зеркальным отображением в состоянии SUSPENDED (это называется работой в незащищенном режиме, поскольку в это время зеркальное отображение базы данных не производится). Когда зеркальный сервер снова подключается к сеансу, он восстанавливает кворум в роли зеркального и заново начинает синхронизацию своей копии базы данных.
Соединение с основным сервером теряется, а следящий и зеркальный серверы удерживают кворум.
В этом случае происходит автоматический переход на другой ресурс. Дополнительные сведения см. в разделе Автоматический переход на другой ресурс.
Изредка возможна ситуация, когда сетевое соединение между участниками зеркального отображения теряется, в то время как оба участника остаются подключенными к следящему серверу. В этом случае существует два отдельных кворума «следящий сервер-участник», причем следящий сервер является соединяющим элементом. Следящий сервер уведомляет зеркальный сервер о том, что основной сервер еще подключен. Поэтому автоматического перехода на другой ресурс не происходит. Зеркальный сервер остается в роли зеркального и ожидает соединения с основным сервером. Если в этот момент в очереди повторного выполнения имеются записи журнала, зеркальный сервер продолжает накат зеркальной базы данных. После восстановления соединения зеркальный сервер заново синхронизирует зеркальную базу данных.
Кворум «участник-участник» состоит из двух участников.
Пока участники удерживают кворум, база данных продолжает функционировать в состоянии SYNCHRONIZED и имеется возможность перехода на другой ресурс вручную. Без следящего сервера автоматический переход на другой ресурс невозможен, но, когда он восстанавливает кворум, сеанс зеркального отображения возобновляется, и автоматический переход на другой ресурс снова поддерживается.
Сеанс теряет кворум.
Если все экземпляры сервера отключены друг от друга, то говорят, что сеанс потерял кворум. Как только экземпляры сервера заново подключатся друг к другу, кворум между ними восстанавливается.
Если основной сервер заново подключается к одному из экземпляров сервера, база данных становится доступной.
Если основной сервер остается отключенным, а зеркальный и следящий заново подключаются друг к другу, то автоматический переход на другой ресурс невозможен из-за возможной потери данных. Поэтому база данных остается недоступной, пока основной сервер вновь не подключится к сеансу.
Когда все три экземпляра сервера снова подключаются друг к другу, восстанавливается полный кворум, и сеанс возобновляет нормальную работу.
| Важно! |
|---|
Когда в сеансе имеется только кворум «участник-участник», то при утере кворума одним из участников другой участник также теряет кворум. Поэтому, если ожидается, что следящий сервер будет оставаться отключенным в течение значительного промежутка времени, рекомендуется временно удалить следящий сервер из сеанса. Удаление следящего сервера удаляет требование кворума. Затем, если зеркальный сервер будет отключен, основной сервер может продолжать обслуживать базу данных. Сведения о добавлении и удалении следящего сервера см. в разделе Следящий сервер зеркального отображения базы данных. |
Влияние кворума на доступность базы данных
На следующем рисунке показано, как взаимодействуют следящий сервер и стороны зеркального отображения, чтобы в один момент времени только одна из сторон выступала в роли основного сервера и только текущий основной сервер мог перевести свою базу данных в оперативный режим. Оба сценария начинаются с полного кворума, Участник A в роли основного сервера и Участник Б в роли зеркального.
.gif "Как взаимодействуют следящий сервер и участники")
В сценарии 1 демонстрируется, как после сбоя в работе исходного основного сервера (Участник A) следящий сервер и зеркальный сервер соглашаются с тем, что основной сервер (Участник A) стал недоступен, и формируют кворум. Затем зеркальный сервер Участник Б принимает на себя роль основного сервера. Производится автоматический переход на другой ресурс, и Участник Б переводит свою копию базы данных в оперативный режим. Затем Участник Б отключается, и его база данных переходит в автономный режим. Затем бывший основной сервер Участник A восстанавливает соединение со следящим сервером, вновь образуя кворум, однако получает от следящего сервера Участник A уведомление о том, что его копия базы данных не может быть переведена в оперативный режим, поскольку роль основного сервера теперь принадлежит Участнику Б. Когда Участник Б вновь присоединяется к сеансу, он переводит базу данных обратно в оперативный режим.
В сценарии 2 следящий сервер теряет кворум, в то время как Участник A и Участник Б сохраняют кворум друг с другом, и база данных остается в оперативном режиме. Затем участники также теряют свой кворум, и база данных переходит в автономный режим. После этого основной сервер Участник A восстанавливает соединение со следящим сервером, вновь образуя кворум. Следящий сервер подтверждает, что роль основного сервера по-прежнему принадлежит Участнику A, и поэтому он переводит базу данных обратно в оперативный режим.
См. также