Одноранговая репликация транзакций
Одноранговая репликация поддерживает масштабируемые и отказоустойчивые решения, сохраняя копии данных на нескольких экземплярах сервера, которые также называются узлами. Одноранговая репликация, основанная на репликации транзакций, распространяет согласованные на уровне транзакций изменения почти в реальном времени. Это позволяет приложениям, для которых требуется масштабируемость операций чтения, распределять клиентские операции чтения на несколько узлов. Поскольку данные сохраняются на узлах почти в режиме реального времени, одноранговая репликация обеспечивает избыточность данных, что повышает доступность данных.
Рассмотрим веб-приложение. В этом случае извлечь выгоду из одноранговой репликации можно следующими способами.
Запросы к каталогам и другие операции чтения распределяются на нескольких узлах. Тем самым повышается производительность и сохраняется согласованность.
Если один из узлов в системе выходит из строя, уровень приложения может перенаправить операции записи на другой узел. Это позволяет сохранить доступность данных.
Если узлу требуется обслуживание или вся система нуждается в обновлении, каждый узел можно перевести в режим «вне сети», а затем опять добавить к системе, не затрагивая доступность приложения.
Хотя одноранговая репликация позволяет масштабировать операции чтения, производительность операций записи для топологии такая же, как для одного узла. Это объясняется тем, что в конце концов все операции вставки, обновления и удаления распространяются на все узлы. Примененное к данному узлу изменение распознается репликацией, что предотвращает выполнение изменений на узлах более одного раза. Настоятельно рекомендуется выполнять операции записи для каждой строки только на одном узле по следующим причинам.
Если строка изменяется на нескольких узлах, это может вызвать конфликт или даже потерю обновления, когда эта строка передается на другие узлы.
При репликации изменений всегда существует некоторая задержка. Для приложений, которым требуется немедленно отслеживать последние изменения, равномерное распределение динамической загрузки может оказаться проблематичным.
Одноранговая репликация в SQL Server 2012 предоставляет возможность включить обнаружение конфликтов во всей одноранговой топологии. Эта возможность помогает избежать проблем, которые вызываются необнаруженными конфликтами, в том числе недопустимым поведением приложения и потерянными обновлениями. При включенном обнаружении конфликтов конфликтующее изменение по умолчанию рассматривается как критическая ошибка, вызывающая сбой агента распространителя. В случае конфликта топология остается в несогласованном состоянии, пока конфликт не будет разрешен вручную, а данные согласованы во всей топологии. Дополнительные сведения см. в разделе Обнаружение конфликтов в одноранговой репликации.
.gif "Примечание") Примечание |
|---|
Чтобы избежать возможной несогласованности данных, убедитесь, что в одноранговой топологии отсутствуют конфликты, даже при включенном обнаружении конфликтов. Чтобы операции записи выполнялись только на одном узле, приложения, получающие доступ к данным и изменяющие их, должны секционировать операции вставки, обновления и удаления. Такое секционирование обеспечивает тот факт, что изменения конкретной строки на одном узле синхронизируются с остальными узлами в топологии, прежде чем эта строка будет изменена другим узлом. Если приложению требуется усложненное обнаружение конфликтов, используйте репликацию слиянием. Дополнительные сведения см. в разделах Репликация слиянием и Обнаружение и разрешение конфликтов репликации слиянием. |
Одноранговые топологии
Типичные способы использования одноранговой репликации проиллюстрированы следующими сценариями.
Топология с двумя участвующими базами данных
.gif "Одноранговая репликация с двумя узлами")
На обоих приведенных выше рисунках показаны две участвующие базы данных и пользовательский трафик, направленный к базам данных через сервер приложений. Такую конфигурацию можно использовать для различных приложений — от веб-сайтов до приложений рабочих групп. Это позволяет получить следующие преимущества.
Улучшенная производительность операции чтения, так как чтение распределено на два сервера.
Более высокая доступность при необходимости обслуживания или в случае сбоя одного из узлов.
На обеих иллюстрациях операция чтения между участвующими базами данных сбалансирована, но обновления обрабатываются разными способами:
Слева операции обновления секционируются между двумя серверами. Если база данных содержит каталог продукции, можно, например, создать пользовательское приложение, направляющее обновления названий продуктов, начинающихся с букв от «А» до «М», на узел А, а обновления продуктов, начинающихся с букв от «Н» до «Я» — на узел Б. Затем обновления реплицируются на другой узел.
Справа все обновления направляются на узел В. С узла «В» обновления реплицируются на узел A. Если узел B находится в режиме «вне сети» (например, на обслуживании), сервер приложений может направлять все операции на узел A. Когда узел B переходит в режим «в сети», на него можно направлять обновления, и сервер приложений может переместить все обновления обратно на узел B или сохранить их передачу на узел A.
Одноранговая репликация поддерживает любой из этих подходов, но основной пример обновления, показанный справа, также часто используется для стандартной репликации транзакций.
Топологии с тремя или более участвующими базами данных
.gif "Одноранговая репликация в распределенные места назначения")
На предыдущем рисунке показаны три участвующие базы данных, предоставляющие данные для глобальной организации по поддержке программного обеспечения с офисами в Лос-Анджелесе, Лондоне и Тайбэе. Инженеры службы поддержки во всех офисах принимают звонки клиентов, вводят и обновляют сведения о каждом звонке. Часовые пояса трех офисов отличаются на восемь часов, поэтому рабочие часы не перекрываются. Когда закрывается офис в Тайбэе, открывается офис в Лондоне. Если звонок находится в стадии обработки во время закрытия одного офиса, он передается представителю в другой открытый офис.
В каждом офисе имеется база данных и сервер приложений, которые используются инженерами службы поддержки для ввода и обновления сведений о звонках клиентов. Топология секционируется по времени. Поэтому обновления происходят на узле, открытом для бизнеса в текущее время, а затем передаются в другие участвующие базы данных. Данная топология обеспечивает следующие преимущества:
Независимость без изоляции: В каждом офисе можно независимо добавлять, обновлять или удалять данные, при этом также можно использовать данные совместно, так как они реплицируются на все участвующие базы данных.
Более высокая доступность в случае сбоя или во время обслуживания одной или нескольких участвующих баз данных.
.gif "Одноранговая репликация с тремя и четырьмя узлами")
На предыдущем рисунке показано добавление узла в топологию с тремя узлами. В этом сценарии узел можно добавить по следующим причинам.
Так как другой офис открыт.
Чтобы обеспечить более высокую доступность в целях поддержки обслуживания или повышения отказоустойчивости при сбое диска или других серьезных неисправностях.
Обратите внимание, что в обеих трех- и четырехузловых топологиях все базы данных публикуют свои данные и подписываются на данные из остальных баз данных. Этим обеспечивается максимальная доступность при проведении обслуживания или в случае сбоя на одном или нескольких узлах. По мере добавления узлов необходимо соблюдать баланс между доступностью и масштабируемостью с одной стороны и производительностью, сложностью развертывания и администрирования с другой стороны.
Настройка одноранговой репликации
Настройка топологии одноранговой репликации очень похожа на настройку серии стандартных публикаций и подписок транзакций. В следующих разделах показан процесс настройки системы из трех узлов, аналогичной конфигурации с одноранговой топологией, которая представлена выше на рисунке слева.
Вопросы использования одноранговой репликации
В этом разделе представлены сведения и рекомендации по использованию одноранговой репликации.
Общие рекомендации
Одноранговая репликация доступна только в Microsoft SQL Server 2012 Enterprise.
Все базы данных, участвующие в одноранговой репликации, должны содержать идентичные схемы и данные.
Имена объектов, схемы объектов и публикаций должны быть идентичными.
Публикации для реплицирования должны разрешать изменения схемы. (То есть свойство публикации 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 2005 к существующей топологии
Добавление статьи к существующей публикации
Изменения схемы
Восстановление узла из резервной копии
Дополнительные сведения см. в разделах заморозить топологию репликации (программирование репликации на языке Transact-SQL) и администрировать одноранговую топологию (программирование репликации на языке Transact-SQL).
Если к одноранговой топологии добавлен новый узел, восстановление необходимо выполнять только из резервных копий, созданных после добавления нового узла.
Повторно инициализировать подписки в одноранговой топологии нельзя. Если нужно убедиться в том, что узел имеет новую копию данных, восстановите резервную копию на этом узле.
См. также
Задания
администрировать одноранговую топологию (программирование репликации на языке Transact-SQL)