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

Область применения: SQL Server (все поддерживаемые версии)

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

Одноранговая репликация в распределенных расположениях

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

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

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

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

    Одноранговая репликация, три и четыре узла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Параметр агента распространителя -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.

  • В CU 13 для SQL Server 2019 (15.x) добавлено свойство публикации @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': замораживание не требуется.

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

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

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

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

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

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

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

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

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

См. также:

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