Статья
09/28/2010

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

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

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

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

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

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

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

Типичные ситуации использования принудительного обслуживания

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

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

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

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

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

Риск использования принудительного обслуживания

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

Примечание
Сведения о вилках восстановления см. в разделе Пути восстановления.

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

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

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

Дополнительные сведения см. в разделе «Управление возможной потерей данных» далее в этой главе.

Управление возможной потерей данных

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

Исходный основной сервер смог восстановить соединение

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

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

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

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

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

Исходный основной сервер не смог восстановить соединение

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

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

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

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

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