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