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

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

Рассмотрим веб-приложение. Это может быть полезно для пиринговой репликации следующими способами:

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

• Если один из узлов в системе выходит из строя, прикладной уровень может перенаправить записи для этого узла на другой узел. Это поддерживает доступность.

• Если для узла требуется обслуживание или для всей системы требуется обновление, каждый узел может быть отключен и добавлен обратно в систему, не влияя на доступность приложения.

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

• Если строка изменяется на нескольких узлах, она может вызвать конфликт или даже потерянное обновление при распространении строки на другие узлы.

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

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

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

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

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

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

• Улучшенная производительность чтения, так как операции чтения распределяются по двум серверам.

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

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

• Слева обновления секционируются между двумя серверами. Если база данных содержит каталог продуктов, вы можете, например, настроить приложение так, чтобы обновления направлялись на узел A для имен продуктов, начинающихся от A до M, и на узел B для имен продуктов, начинающихся от N до Z. Затем обновления реплицируются на другой узел.

• Справа все обновления направляются на узел B. Оттуда обновления реплицируются на узел A. Если B находится в автономном режиме (например, для обслуживания), сервер приложений может направлять все действия в A. При обратном подключении B обновления могут передаваться к нему, и сервер приложений может переместить все обновления обратно в B или продолжать направлять их в A.

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

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

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

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

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

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

  

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

• Так как открывается другой офис.

• Чтобы обеспечить более высокую доступность для поддержки обслуживания или повышения отказоустойчивости, если произошел сбой диска или другой серьезный сбой.

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

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

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

Соображения по использованию одноранговой репликации

В этом разделе представлена информация и рекомендации для учета при использовании одноранговой репликации.

Общие рекомендации

• Репликация по типу "одноранговая" доступна только в корпоративных версиях SQL Server.

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

  • Имена объектов, схема объектов и имена публикаций должны совпадать.

  • Публикации должны разрешать репликацию изменений схемы. (Это параметр 1 для свойства публикации replicate_ddl, который является параметром по умолчанию.) Дополнительные сведения см. в разделе "Внесение изменений в схему" в базах данных публикации.

  • Фильтрация строк и столбцов не поддерживается.

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

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

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

• Подписки должны быть инициализированы с помощью резервной копии или с параметром "Только поддержка репликации". Дополнительные сведения см. в разделе "Инициализация транзакционной подписки без моментального снимка".

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

Ограничения компонентов

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

• Инициализация и повторная инициализация с помощью моментального снимка.

• Фильтры строк и столбцов.

• Столбцы метки времени.

• Издатели и подписчики, не использующие 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 2005 в существующую топологию

• Добавление статьи в существующую публикацию

• Внесение изменений в схему

• Восстановление узла из резервной копии

Дополнительные сведения см. в разделе "Приостановка топологии репликации" (Программирование Transact-SQL репликации) и "Администрирование одноранговой топологии" (Программирование Transact-SQL репликации).

• При добавлении нового узла в одноранговую топологию необходимо восстановить только из резервных копий, созданных после добавления нового узла.

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

См. также

Администрирование одноранговой топологии (программирование репликации на языке Transact-SQL)
Стратегии резервного копирования и восстановления снимков и транзакционной репликации
Типы публикаций для репликации транзакций