Повышение доступности
Репликация может использоваться для передачи данных на резервный сервер, который обеспечивает повышенную доступность в случае плановых или внеплановых отключений системы. Репликацию необходимо использовать для обеспечения горячего резервирования, если данные, необходимые на резервном сервере, представляют собой подмножество данных на сервере-источнике. Также нужно принимать во внимание следующее:
Если для приложения необходимо наличие данных в нескольких узлах с целью повышения масштабируемости и доступности, см. дополнительные сведения в разделе Повышение доступности и масштабируемости.
Если для приложения необходима доступность всей базы данных на резервном сервере, то надо использовать зеркальное отображение базы данных, а не репликацию. Зеркальное отображение базы данных является более эффективным, если требуется синхронизация всей базы данных и отсутствует необходимость в использовании сервера-получателя для обработки запросов. Дополнительные сведения см. в разделе Администрирование зеркального отображения базы данных.
На нижеприведенной схеме показан сервер-источник и один резервный сервер, при этом подмножество данных сервера-источника доступно на сервере-получателе.
.gif "Репликация данных на резервный сервер")
.gif "Примечание") Примечание |
|---|
Репликация не предоставляет механизм для экстренного переключения с одного сервера на другой, резервный, сервер. Те приложения, которые требуют доступ к заданному серверу, необходимо запрограммировать на использование другого сервера в случае недоступности первого. |
Пример компании Adventure Works Cycles
Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Образцы баз данных AdventureWorks.
Adventure Works Cycles имеет несколько серверов в производственных цехах, которые собирают данные о дефектах, обнаруживаемых на производственных линиях. Для обеспечения доступности этих серверов используется репликация. Был разработан программный код для перенаправления запросов на сервер горячего резервирования во время плановых и внеплановых отключений.
Общие требования для этого сценария
Приложения, использующие репликацию для обеспечения доступности, обычно предъявляют следующие требования, выполнение которых должно обеспечиваться соответствующим решением для репликации:
Система должна поддерживать согласованность транзакций.
Система должна иметь небольшую задержку: обновления на одном сервере должны быстро поступать на другие серверы.
Система должна иметь высокую пропускную способность: требуется обрабатывать репликации большого числа транзакций.
Для обработки репликации должен требоваться минимальный объем служебных операций.
Данные, требуемые на сервере-получателе, могут быть подмножеством данных сервера-источника (см. первую схему выше).
Типы репликации, доступные для использования в этом сценарии
MicrosoftSQL Server использует метафору издательского дела для описания компонентов системы репликации. Компоненты включают издатель, подписчики, публикации, статьи и подписки.
На вышеприведенной схеме сервер-источник является издателем. Некоторые или все данные на сервере-источнике включаются в публикацию, при этом каждая таблица данных является статьей (статьями также могут быть другие объекты базы данных, например хранимые процедуры). Резервный сервер является подписчиком на публикацию, получающим схему и данные в виде подписки. Дополнительные сведения о компонентах системы см. в разделе Обзор модели публикации репликации.
SQL Server предлагает различные типы репликации в соответствии с различными требованиями приложений: репликация моментальных снимков, репликация транзакций и репликация слиянием. Данный сценарий лучше всего реализуется с помощью репликации транзакций, которая хорошо справляется с требованиями, описанными в предыдущем разделе. Дополнительные сведения о репликации транзакций см. в разделах Обзор репликации транзакций и Как работает репликация транзакций.
По своей конструкции репликации транзакций удовлетворяют главным требованиям этого сценария:
согласованность транзакций;
небольшая задержка;
высокая пропускная способность;
минимальный издержки.
Основным параметром, который нужно учитывать в этом сценарии, является фильтрация. Репликация транзакций позволяет фильтровать столбцы и строки, так что таблицы у подписчика будут содержать только данные, необходимые для приложения. Дополнительные сведения см. в разделе Фильтрование опубликованных данных.
Шаги по реализации этого сценария
Чтобы реализовать этот сценарий, прежде всего необходимо создать публикацию и подписки, а затем инициализировать каждую подписку. Чтобы получить дополнительные сведения по каждому шагу, щелкните ссылки, приводимые ниже:
После того как подписка инициализирована и выполняется обмен данными между издателем и подписчиками, возможно, потребуется ознакомиться с дополнительными сведениями в следующих разделах, в которых рассматриваются общие задачи администрирования и контроля: