Глава 20

Репликация

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

Итак, в настоящей главе приведено подробное описание средств репликации, предусмотренных в версии SQL Server 2005. Причем изложение материала в основном рассчитано на тех, кто только знакомится с этими вопросами. Следует отметить, что репликация относится к тем направлениям эксплуатации СУБД, о которых стараются не вспоминать до тех пор, пока не появится необходимость в их использовании. А после возникновения такой ситуации внезапно обнаруживается, что положение критическое, и требуется немедленно изучить все, что относится к проблематике репликации, и ввести средства репликации в действие (причем, к сожалению, на достаточно подробное изучение этой темы часто не хватает времени).

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

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

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

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

Предоставление доступа к данным с тех клиентских компьютеров, которые подключаются к сети только время от времени.

Распределение больших объемов нагрузки, связанной с формированием отчетов.

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

Дублирование данных БД, распределенных на большой территории.

В этом перечне указаны лишь некоторые из причин, по которым следует использовать репликацию.

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

В настоящей главе рассматриваются перечисленные ниже темы.

Общие понятия репликации.

Доступные модели репликации (в связи с этим приведено несколько примеров).

Проблемы обеспечения безопасности (в этой области в версии SQL Server 2005 произошли значительные изменения).

Программная реализация средств управления репликацией на основе объектов управления репликацией (Replication Management Objects - RMO).

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

Основы репликации

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

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

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

автономность;

время задержки;

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

Ниже приведено краткое описание каждого из этих факторов. Автономность

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

Время задержки

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

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