Одноранговая репликация транзакций

Изменения: 12 декабря 2006 г.

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

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

Примечание.

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

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

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

Одноранговые топологии

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

Топология с двумя участвующими базами данных

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

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

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

• Слева обновления секционируются между двумя серверами. Если база данных содержит каталог продуктов, то, например пользовательское приложение может непосредственно обновить в узле «А» продукты с названиями, начинающимися на буквы А-М, а в узле «В» — продукты с названиями, начинающимися на буквы N-Z. Обновления затем реплицируются на другой узел.
• Справа все обновления направляются на узел «В». С узла «В» обновления реплицируются на узел «А». Если узел «В» находится в автономном режиме (например, на обслуживании), сервер приложений может направлять все операции на узел «А». Когда узел «В» переходит в оперативный режим, на него можно направлять обновления, и сервер приложений может переместить все обновления обратно на узел «В» или сохранить их передачу на узел «А».

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

Топологии с тремя или более участвующими базами данных

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

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

• Независимость без изоляции: в каждом офисе можно независимо добавлять, обновлять или удалять данные, при этом также можно использовать данные совместно, так как они реплицируются на все участвующие базы данных.
• Более высокая доступность в случае сбоя или во время обслуживания любой из участвующих баз данных.
  

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

• Так как другой офис открыт.
• Чтобы обеспечить высокую доступность для поддержки и обслуживания или повысить отказоустойчивость в случае глобального сбоя.
• Обратите внимание, что в обеих топологиях (с тремя и четырьмя узлами) все базы данных имеют возможность публикации и подписки на остальные базы данных, что обеспечивает максимальную доступность во время обслуживания или при сбое одного или нескольких узлов. По мере добавления узлов необходимо соблюдать баланс между доступностью и масштабируемостью с одной стороны и производительностью, сложностью развертывания и администрирования с другой стороны.

Настройка одноранговой репликации

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

Настройка одноранговой репликации транзакций

• 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 Enterprise Edition.
• Все участвующие базы данных должны содержать идентичные схемы и данные:
  • Имена объектов, схемы объектов и публикаций должны быть идентичными во всех участвующих базах данных.
  • Публикации должны допускать репликацию изменений схемы (свойство публикации replicate_ddl должно иметь значение 1, что является значением по умолчанию). Дополнительные сведения см. в разделе Внесение изменений схем в базы данных публикаций.
  • Фильтрация строк и столбцов не поддерживается.
• Рекомендуется в каждом узле использовать собственную базу данных распространителя. Это исключит возможность образования одной точки сбоя.
• Таблицы и другие объекты нельзя включать в несколько одноранговых публикаций в отдельной базе данных публикации.
• Публикация должна быть доступна для одноранговой репликации до создания подписок.
• Подписки должны быть инициализированы с помощью резервного копирования или параметра «только поддержка репликации». Дополнительные сведения см. в разделе Инициализация подписки на публикацию транзакций без моментального снимка.
• Обнаружение и разрешение конфликтов отсутствует. Обновления заданной строки следует выполнять только в одной базе данных, пока она не синхронизирована с другими узлами. Это условие можно выполнить, например с помощью приложения, направляющего обновления для набора строк на отдельный узел.
• Использовать столбцы идентификаторов не рекомендуется. При использовании идентификаторов необходимо вручную управлять диапазонами, назначенными таблицам, в каждой участвующей базе данных. Дополнительные сведения см. в подразделе «Назначение диапазонов для ручного управления диапазонами идентификаторов» раздела Репликация столбцов идентификаторов.

Функциональные ограничения

Одноранговая репликация поддерживает ключевые свойства репликации транзакций. Эта репликация не поддерживает следующие функции:

• Инициация и повторная инициация с помощью моментальных снимков.
• Фильтрация строк и столбцов.
• Столбцы временных меток.
• Издатели и подписчики, отличные от SQL Server.
• Немедленно обновляемые подписки и подписки, обновляемые посредством очередей.
• Анонимные подписки.
• Частичные подписки.
• Присоединяемые и трансформируемые подписки (те и другие в SQL Server 2005 являются устаревшими).
• Общие агенты распространителя.
• Параметр агента распространителя -SubscriptionStreams и параметр агента чтения журнала -MaxCmdsInTran.
• Свойства статьи @destination_owner и @destination_table.

Следующие свойства имеют особые соглашения.

• Свойство публикации @allow_initialize_from_backup должно иметь значение 'true'.
• Свойство статьи @replicate_ddl должно иметь значение TRUE, свойство @identityrangemanagementoption — 'manual', а свойство @status — значение '24'.
• Свойствам статьи @ins_cmd, @del_cmd и @upd_cmd не может быть задано значение 'SQL'.
• Свойство подписки @sync_type должно быть установлено в значение 'none' или 'automatic'.

Вопросы обслуживания

• Следующие операции требуют приостановки системы (остановки операций с опубликованными таблицами на всех узлах с гарантией получения каждым узлом всех изменений от всех других узлов):
  • Добавление узла к существующей топологии
  • Добавление статьи к существующей публикации
  • Изменения схемы
  • Восстановление узла из резервной копии
    Дополнительные сведения см. в разделе Как настроить одноранговую репликацию транзакций (среда SQL Server Management Studio), How to: Quiesce a Replication Topology (Replication Transact-SQL Programming) и How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming).
• Если к одноранговой топологии добавляется новый узел, восстановление следует производить только из резервных копий, которые были созданы после его добавления. Дополнительные сведения см. в разделе Как настроить одноранговую репликацию транзакций (среда SQL Server Management Studio).
• В одноранговой топологии невозможно повторно инициализировать подписки. Если нужно убедиться в том, что узел имеет новую копию данных, восстановите резервную копию на этом узле.

Журнал изменений

См. также

Основные понятия

Стратегии резервного копирования и восстановления из копии репликации моментальных снимков и репликации транзакций
Типы публикации для репликации транзакций

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

How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming)

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

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