Повышение доступности и масштабируемости
Во многих приложениях критически важным является обеспечение более высокой доступности и более высокой масштабируемости чтения; в качестве ключевой части решения этих двух задач может быть использована репликация. Для некоторых приложений может возникать необходимость в повышении либо доступности, либо масштабируемости с помощью репликации. Если необходимо решать только одну из этих задач, рассмотрите следующие сценарии:
На приведенных ниже схемах показаны два приложения, которым применение репликации позволяет повысить доступность и масштабируемость. В обоих случаях три базы данных на схемах являются равноправными по отношению друг к другу: они содержат идентичные схемы и данные. Операции записи для этих баз данных должны быть секционированы: если бы база данных содержала каталог продуктов, можно, например направлять обновления в первую базу данных для имен продуктов, начинающихся с букв A-I, во вторую базу данных — с букв J-R и в третью базу данных — с букв S-Z. Затем обновления реплицируются в другие базы данных.
На первой схеме показана конфигурация, в которой каждый веб-сервер и сервер приложений использует данные с определенного кэширующего сервера. Операции чтения и обновления для заданного пользователя направляются определенному серверу приложений и затем — определенному кэширующему серверу. Так как сервер приложений обновляет кэш непосредственно, центральный исходный сервер не требуется. Обновления каждого кэша распространяются в другие кэши.
.gif "Использование репликации для масштабирования считывания данных")
На второй схеме показаны три территориально распределенных сервера, между которыми происходит обмен потоками данных, что позволяет каждому из этих серверов поддерживать запросы чтения и повышать доступность.
.gif "Одноранговая репликация в распределенные места назначения")
Пример Adventure Works Cycles
Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Образцы баз данных AdventureWorks2008R2.
Adventure Works Cycles имеет ряд офисов по всему миру, включая Лос-Анджелес, Лондон и Тайбэй. Сведения о заказах клиентов собираются в каждом из офисов и затем реплицируется в другие места.
Сведения о заказах могут считываться из любого офиса. Если подразделение в Лондоне загружено обработкой большого объема заказов, то внутренние приложения могут распределить часть этой нагрузки на два других офиса.
Если, например офисный сервер в Лондоне отключается по причине технического обслуживания, то заказы можно продолжать получать из другого места и работники офиса в Лондоне могут продолжать считывать и вводить данные. После того как сервер в Лондоне снова будет переведен в рабочий режим, полученные за время его отключения изменения будут скопированы на сервер: таким образом, на нем будут самые последние данные.
Общие требования для этого сценария
Приложения, использующие репликацию для обеспечения масштабируемости и доступности, обычно предъявляют следующие требования, которые должны выполняться соответствующим решением репликации:
Система должна позволять вносить изменения на любом сервере и реплицировать эти изменения на все другие серверы.
Система должна поддерживать согласованность транзакций.
Система должна иметь небольшую задержку: обновления на одном сервере должны быстро поступать на другие серверы.
Система должна иметь высокую пропускную способность: она должна обрабатывать репликации большого числа транзакций.
Обработка репликации должна требовать минимальной дополнительной нагрузки.
Типы репликации, доступные для использования в этом сценарии
Microsoft SQL Server использует метафору издательского дела для описания компонентов системы репликации. Компоненты включают издатель, подписчики, публикации, статьи и подписки.
На вышеприведенных схемах все кэширующие серверы являются издателями и подписчиками. Все данные реплицируемой базы данных на каждом сервере включаются в публикацию, а каждая таблица данных является статьей (статьями также могут быть другие объекты баз данных, например хранимые процедуры). Каждый сервер подписывается на публикации других серверов, получая в качестве подписки схему и данные. Дополнительные сведения о компонентах системы см. в разделе Обзор модели публикации репликации.
SQL Server предлагает разные виды репликации для разных требований приложений: репликацию моментальных снимков, репликацию транзакций и репликацию слиянием. Этот сценарий лучше всего реализуется с помощью одноранговой репликации транзакций, которая хорошо подходит для обработки требований, описанных в общих чертах в предыдущем разделе. Дополнительные сведения об одноранговой репликации транзакций см. в разделе Одноранговая репликация транзакций.
.gif "Примечание") Примечание |
|---|
Если приложению необходимо внести в конкретную строку изменения более чем на одном узле одновременно, то могут возникать конфликты. В этом случае следует воспользоваться репликацией слиянием, которая хорошо подходит для обработки конфликтов. Дополнительные сведения о репликации слиянием см. в разделе Обзор репликации слиянием. |
По своей структуре репликации транзакций выполняют основные требования этого сценария:
изменения можно вносить на любом сервере;
согласованность транзакций;
небольшая задержка;
высокая пропускная способность;
минимальный объем служебных операций.
Одноранговый вариант репликации транзакций позволяет серверам выполнять публикации и подписки в отношении одних и тех же данных. Все узлы одноранговой топологии являются равноправными: каждый узел публикует и подписывается на одни и те же схемы и данные. Изменения (вставки, обновления и удаления) можно вносить на всех узлах и затем реплицировать их на все остальные узлы.
Шаги по реализации этого сценария
Чтобы реализовать данный сценарий, необходимо сначала создать публикацию и подписки, а затем инициализировать каждую подписку. Дополнительные сведения см. в следующих разделах.
Среда SQL Server Management Studio: Как настроить одноранговую репликацию транзакций (среда SQL Server Management Studio)
Программирование репликации на языке Transact-SQL: Как настроить одноранговую репликацию транзакций (программирование репликации на языке Transact-SQL)
После того как подписки инициализированы и между узлами выполняется обмен данными, возможно, потребуются дополнительные сведения об общих задачах администрирования и контроля, которые можно найти в следующих разделах: