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

  • Статья

Применимо к:SQL Server

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

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

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

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

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

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

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

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

Одноранговая репликация содержит возможность включить обнаружение конфликтов во всей одноранговой топологии. Эта возможность помогает избежать проблем, которые вызываются необнаруженными конфликтами, в том числе недопустимым поведением приложения и потерянными обновлениями. При включенном обнаружении конфликтов конфликтующее изменение по умолчанию рассматривается как критическая ошибка, вызывающая сбой агента распространителя. В случае конфликта топология остается в несогласованном состоянии, пока конфликт не будет разрешен вручную, а данные согласованы во всей топологии. Дополнительные сведения см. в разделе Conflict Detection in Peer-to-Peer Replication.

Примечание.

Чтобы избежать возможной несогласованности данных, убедитесь, что в одноранговой топологии отсутствуют конфликты, даже при включенном обнаружении конфликтов. Чтобы операции записи выполнялись только на одном узле, приложения, получающие доступ к данным и изменяющие их, должны секционировать операции вставки, обновления и удаления. Такое секционирование обеспечивает тот факт, что изменения конкретной строки на одном узле синхронизируются с остальными узлами в топологии, прежде чем эта строка будет изменена другим узлом. Если приложению требуется усложненное обнаружение конфликтов, используйте репликацию слиянием. Дополнительные сведения см. в статьях Merge Replication (Репликация слиянием) и Detect and Resolve Merge Replication Conflicts (Обнаружение и разрешение конфликтов репликации слиянием).

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

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

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

Peer-to-peer replication, two nodes

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

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

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

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

  • Слева операции обновления секционируются между двумя серверами. Если база данных содержит каталог продукции, можно, например, создать пользовательское приложение, направляющее обновления продуктов, начинающихся символами с «А» до «М», на узел A , а обновления продуктов с «Н» до «Я» — на узел B .

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

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

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

Peer-to-peer replication to dispersed locations

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

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

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

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

    Peer-to-peer replication, three and four nodes

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

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

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

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

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

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

Вопросы использования одноранговой репликации

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

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

  • Одноранговая реплика tion доступна только в корпоративном выпуске SQL Server.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Издатели и подписчики, отличные от SQL Server.

  • Немедленно обновляемые подписки и подписки, обновляемые посредством очередей.

  • Анонимные подписки.

  • Частичные подписки.

  • Присоединяемые подписки и трансформируемые подписки. (Оба этих варианта не рекомендуется использовать в SQL Server 2005 (9.x).)

  • Общие агенты распространителя.

  • Параметр агента распространителя -SubscriptionStreams и параметр агента чтения журнала -MaxCmdsInTran.

  • Свойства статьи @destination_owner и @destination_table.

  • Одноранговая транзакционная реплика tion не поддерживает создание односторонняя подписка на одноранговую публикацию

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

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

  • Свойство публикации @allow_initialize_from_backup должно иметь значение true.

  • Свойство статьи @replicate_ddl должно иметь значение true, свойство @identityrangemanagementoption должно иметь значение manual, а свойство @status — значение 24.

  • Значение свойств @ins_cmdстатьи и @upd_cmd@del_cmdне может быть задано для SQL.

  • Свойство подписки @sync_type должно иметь значение none или automatic.

  • SQL Server 2019 (15.x) CU 13 представляет свойство публикации. @p2p_confictdetection_policy По умолчанию параметру задано значение originatorid, которое разрешает конфликт на основе идентификатора инициатора. Значение параметра lastwriter разрешает конфликт на основе последнего модуля записи.

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

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

Действие Только одноранговые узлы SQL Server 2005 или сочетание узлов SQL Server 2005 с узлами SQL Server 2008 или более поздней версии. Только одноранговые узлы SQL Server 2005 или сочетание узлов SQL Server 2005 с узлами SQL Server 2008 или более поздней версии. Одноранговые узлы SQL 2008 и более поздние версии Одноранговые узлы SQL 2008 и более поздние версии
Добавление узла к топологии 2 узла в полной топологии: замораживание не требуется. Используйте sync_type = 'initialize with backup'. Более 2 узлов: требуется замораживание. sync_type = 'replication support only': требуется замораживание. sync_type = 'initialize with backup' и 'initialize from lsn': замораживание не требуется.

Для изменения схемы топологии (добавление или удаление статьи) требуется замораживание. Дополнительные сведения см. в статье Администратор ister a Peer-to-Peer Topology (Replication Transact-SQL Programming).

Для удаления узла из топологии никогда не требуется замораживание.

Для изменения свойств статьи с помощью sp_changearticle никогда не требуется замораживание. Допустимыми изменениями (для P2P) являются свойства description, ins_cmd, upd_cmdи del_cmd .

Для изменения схемы статьи (добавление или удаление столбца) никогда не требуется замораживание.

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

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

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

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

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

См. также

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