в центральную базу данных, чтобы на центральном складе всегда имелись достаточные запасы профильных товаров (иначе в магазинах возникнет дефицит нужных товаров).

Согласованность данных

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

Достижение сходимости данных. Обеспечение того, чтобы на всех узлах в конечном итоге хранились совпадающие значения данных; тем не менее на какое-то время значения данных становятся несовпадающими, поскольку изменения, внесенные на одном сервере, еще не были распространены по другим серверам. В качестве примера можно упомянуть указанную выше ситуацию несвоевременного пополнения запасов. В услови51х нехватки запасов приходится особенно внимательно контролировать синхронизацию выполняемых операций, чтобы после передачи всего объема товара в один из двух магазинов другой магазин мог определить, что нужный товар отсутствует, и отказаться от своего заказа. Если же такая синхронизация не обеспечивается, то ни одна заявка на доставку товара в эти магазины не отвергается, в результате чего оказывается, что количество товара, подлежащего доставке, превышает уровень запасов на центральном складе. Как нарушение сходимости данных рассматривается и такая ситуация, в которой в конечном итоге каждый раз достигается синхронизация данных, но при этом последовательность достижения установившего состояния не является одинаковой (иными словами, изменяется порядок фактического проведения обновлений в зависимости от того, сколько узлов участвует в репликации и в какое время происходит их синхронизация).

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

Согласованность схемы

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

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

Следует помнить, что изменение схемы любого объекта базы данных по существу равносильно модификации основ всей системы (или по крайней мере той части системы, к которой относится рассматриваемый объект), независимо от того, применяется ли в системе репликация или нет. Изменения в схеме всегда должны рассматриваться как достаточно серьезные преобразования, поэтому требуют тщательного анализа и методического планирования. Безусловно, некоторые изменения (особенно добавления) обычно могут осуществляться без достаточно значительных побочных последствий. Но такие преобразования схемы, которые приводят к модификации или удалению существующих объектов, могут вызвать самые отрицательные последствия, особенно если в базе данных приходится обращаться к ранее полученным данным. Кроме того, следует учитывать, что многие приложения созданы на основе существующей системы и в них доступ к данным осуществляется с учетом того, какие объекты относятся к текущей схеме и какое они имеют определение, поэтому модификация применяемой схемы может повлечь за собой такие последствия, которые трудно предвидеть заранее.

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

Сразу после того, как в СУБД SQL Server была реализована концепция репликации изменений схемы, эта задача осуществлялась с использованием специальных хранимых процедур sp repladdcolumn и sp repldropcolumn, а не с помощью более известной команды ALTER TABLE. В версии SQL Server 2005 применяетея другой подход к репликации изменений схемы, гюэшому процедуры sp repladdcolumn и sp repldropcolumn рассматриваются как устаревшие (в связи с чем следует избегать их использования).

Другие соображения, связанные с применением репликации

Ниже перечислены некоторые другие факторы, которые следует учитывать при организации репликации.

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

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

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

С показателем задержки соединения тесно связан такой фактор, как пропускная способность. Для оценки пропускной способности необходимо знать, какой объем данньгх должен передаваться через соединение и какое количество соединений должно поддерживаться одновременно в одной и той же линии связи. От этого может зависеть решение о применении методов сжатия при передаче данньгх, относящихся к репликации.

Еще одним важным соображением является необходимость применения для репликации постоянных соединений. Кроме того, следует предусмотреть использование определенного способа организации работы в той ситуации, когда нарушается связь с отдельными серверами. В СУБД SQL Server поддерживается модель репликации в услови51х отсутствия постоянных соединений, но при этом необходимо обеспечить решение всех задач синхронизации в периоды обновления.

Роли объектов, участвующих в репликации

Процесс репликации основан на использовании трех фундаментальных ролей: издатель, распределитель и подписчик. В прршципе любой сервер может выполнять одну (или несколько) из указанных ролей. Системы репликации могут иметь весьма раз-вит)то структуру, как показано на рис. 20. L

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

Издатель

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

Распределитель

Задача выполнения правил распространения информации возложена именно на распределитель. Распределитель- это специальная база данных, предназначенная для распространения информации, которая позволяет отслеживать изменения, а также контролировать то, какими подписчиками эти изменения уже были получены. Кроме того, распределитель проверяет результаты всех процессов синхронизации, что позволяет узнать, какие события произошли при возникновении любых конфликтов, которые должны быть разрешены (информация об устранении конфликтов будет приведена ниже).