Одноранговая репликация поддерживает масштабируемые и отказоустойчивые решения, сохраняя копии данных на нескольких экземплярах сервера, которые также называются узлами.
Типичные способы использования одноранговой репликации проиллюстрированы следующими сценариями.
Топология с двумя участвующими базами данных
На обеих иллюстрациях операция чтения между участвующими базами данных сбалансирована, но обновления обрабатываются разными способами:
• Слева операции обновления доступна на любом сервере.
• Справа все обновления направляются на узел Б. С узла «Б» обновления реплицируются на узел A.
Одноранговая репликация поддерживает любой из этих подходов, но пример обновления, показанный справа, используется для стандартной репликации транзакций.
Одноранговая репликация, основанная на репликации транзакций, распространяет согласованные на уровне транзакций изменения почти в реальном времени. Это позволяет приложениям распределять клиентские операции чтения на несколько узлов. Поскольку данные сохраняются на узлах почти в режиме реального времени, одноранговая репликация обеспечивает избыточность данных, что повышает доступность данных.
Выгоду из одноранговой репликации можно следующими способами.
• Запросы распределяются на нескольких узлах. Тем самым повышается производительность и сохраняется согласованность.
• Если один из узлов в системе выходит из строя, уровень приложения может перенаправить операции записи на другой узел. Это позволяет сохранить доступность данных.
• Если узлу требуется обслуживание или вся система нуждается в обновлении, каждый узел можно перевести в автономный режим, а затем опять добавить к системе, не затрагивая доступность приложения.
• Примененное к данному узлу изменение распознается репликацией, что предотвращает необходимость выполнение изменений на узлах более одного раза.
Настоятельно рекомендуется выполнять операции записи для каждой строки только на одном узле. Попытка изменения строки одновременно на нескольких узлах может вызвать конфликт или даже потерю обновления, когда эта строка передается на другие узлы.
Одноранговая репликация в SQL Server 2008 предоставляет возможность включить обнаружение конфликтов во всей одноранговой топологии.
Чтобы избежать возможной несогласованности данных, убедитесь, что в одноранговой топологии отсутствуют конфликты.
Если публикация включена для одноранговой репликации транзакций, таблицы не могут быть отфильтрованы. Чтобы операции записи выполнялись только на одном узле, приложения, получающие доступ к данным и изменяющие их, должны секционировать операции вставки, обновления и удаления.
Такое секционирование обеспечивает тот факт, что изменения конкретной строки на одном узле синхронизируются с остальными узлами в топологии, прежде чем эта строка будет изменена другим узлом, например:
v Предположим, что база данных содержит каталог продукции. Тогда можно, например, обновления продуктов, начинающихся символами с «А» до «М», осуществлять на узле A, а обновления продуктов с «Н» до «Я» — на узле Б.
v На рисунке показаны три базы данных, предоставляющие данные для глобальной организации с офисами в Лос-Анджелесе, Лондоне и Тайбэе.
Инженеры службы поддержки во всех офисах принимают звонки клиентов, вводят и обновляют сведения о каждом звонке. В каждом офисе имеется база данных и сервер приложений, которые используются инженерами службы поддержки для ввода и обновления сведений о звонках клиентов.
Часовые пояса трех офисов отличаются на восемь часов, поэтому рабочие часы не перекрываются. Когда закрывается офис в Тайбэе, открывается офис в Лондоне.
Топология секционируется по времени. Поэтому обновления происходят на узле, открытом для бизнеса в текущее время, а затем передаются в другие участвующие базы данных.
Настройка топологии одноранговой репликации очень похожа на настройку серии стандартных публикаций и подписок транзакций. В заданиях требуется выполнить процесс настройки системы из двух узлов, аналогичной конфигурации с одноранговой топологией, которая представлена выше на рисунке слева.
Общий подход к созданию топологии из двух узлов (Сервера A и Сервера B):
1. Убедитесь в том, что агент SQL Server запущен на каждом узле. Настройте распространение на Сервере A и Сервере B.
2. Инициализируйте схему и данные на Сервере B вручную или при помощи
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.