Повышение доступности и масштабируемости

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

• Повышение доступности
• Повышение масштабируемости

На приведенных ниже схемах показаны два приложения, которым применение репликации позволяет повысить доступность и масштабируемость. В обоих случаях три базы данных на схемах являются равноправными по отношению друг к другу: они содержат идентичные схемы и данные. Операции записи для этих баз данных должны быть секционированы: если бы база данных содержала каталог продуктов, можно, например направлять обновления в первую базу данных для имен продуктов, начинающихся с букв A-I, во вторую базу данных — с букв J-R и в третью базу данных — с букв S-Z. Затем обновления реплицируются в другие базы данных.

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

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

Пример Adventure Works Cycles

Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Примеры и образцы баз данных.

Adventure Works Cycles имеет ряд офисов по всему миру, включая Лос-Анджелес, Лондон и Тайбэй. Сведения о заказах клиентов собираются в каждом из офисов и затем реплицируется в другие места.

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

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

Общие требования для этого сценария

Приложения, использующие репликацию для обеспечения масштабируемости и доступности, обычно предъявляют следующие требования, которые должны выполняться соответствующим решением репликации:

• Система должна позволять вносить изменения на любом сервере и реплицировать эти изменения на все другие серверы.
• Система должна поддерживать согласованность транзакций.
• Система должна иметь небольшую задержку: обновления на одном сервере должны быстро поступать на другие серверы.
• Система должна иметь высокую пропускную способность: она должна обрабатывать репликации большого числа транзакций.
• Обработка репликации должна требовать минимальной дополнительной нагрузки.

Типы репликации, доступные для использования в этом сценарии

Microsoft SQL Server использует метафору издательского дела для описания компонентов системы репликации. Компоненты включают издатель, подписчики, публикации, статьи и подписки.

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

SQL Server предлагает разные виды репликации для разных требований приложений: репликацию моментальных снимков, репликацию транзакций и репликацию слиянием. Этот сценарий лучше всего реализуется с помощью одноранговой репликации транзакций, которая хорошо подходит для обработки требований, описанных в общих чертах в предыдущем разделе. Дополнительные сведения об одноранговой репликации транзакций см. в разделе Одноранговая репликация транзакций.

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

По своей структуре репликации транзакций выполняют основные требования этого сценария:

• изменения можно вносить на любом сервере;
• согласованность транзакций;
• небольшая задержка;
• высокая пропускная способность;
• минимальный объем служебных операций.

Одноранговый вариант репликации транзакций позволяет серверам выполнять публикации и подписки в отношении одних и тех же данных. Все узлы одноранговой топологии являются равноправными: каждый узел публикует и подписывается на одни и те же схемы и данные. Изменения (вставки, обновления и удаления) можно вносить на всех узлах и затем реплицировать их на все остальные узлы.

Шаги по реализации этого сценария

Чтобы реализовать данный сценарий, необходимо сначала создать публикацию и подписки, а затем инициализировать каждую подписку. Дополнительные сведения см. в следующих разделах.

• Среда SQL Server Management Studio: Как настроить одноранговую репликацию транзакций (среда SQL Server Management Studio)
• Программирование репликации на языке Transact-SQL: How to: Configure Peer-to-Peer Transactional Replication (Replication Transact-SQL Programming)

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

• Мониторинг репликации
• Стратегии резервного копирования и восстановления из копии репликации моментальных снимков и репликации транзакций
• Диагностика при репликации
• Удаление репликации

См. также

Другие ресурсы

Репликация данных в серверной среде

Справка и поддержка

Получение помощи по SQL Server 2005