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