Главная » Microsoft SQL Server, Базы данных » Модель репликации от Microsoft

0

Модель репликации, предложенная компанией Microsoft, основана на сервере репликаций от Sybase (собственно, и сам сервер баз данных SQL Server основан на решениях Sybase). Компоненты репликации SQL Server входят во все варианты поставки, кроме SQL Server 2005 Express и SQL 2005 Mobile Edition. В то же время обе эти редакции могут являться подписчиками публикаций SQL Server 2005. (SQL Server 2005 Mobile Edition является новой версией SQL СЕ, которая запускается на карманных компьютерах и смарт-устройствах. Она может быть только подписчиком публикаций слияния.) Модель Microsoft использует метафоры периодических изданий. (В следующих подразделах будет описан каждый из этих компонентов.) В поставку SQL Server 2000 были включены примеры программ, иллюстрирующих публикации из гетерогенных серверов в среде SQL Server. Все эти функции остались доступными и в SQL Server 2005.

Издатель

Издателем называют сервер-источник, который содержит реплицируемые объекты и данные. Обычно издателем является SQL Server 2005, однако им может быть SQL Server 2000 и Oracle Server. SQL Server поставляется с провайдером репликаций, позволяющим создавать издателей сторонних серверов баз данных.

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

Подписчик

Подписчик в модели репликации получает схему объектов и их данные (т.е. подписку) от издателя. Каждый подписчик может получать несколько подписок от разных издателей. Подписчиками могут выступать SQL Server 2005, SQL Server 2005 Mobile Edition, SQL Server 2000 и SQL Server 7. Большей своей частью подписки доступны только для чтения, однако существуют некоторые типы репликаций, позволяющие подписчикам публиковать данные у издателя.

Распространитель

Распространителем называют SQL Server, который распространяет схему, данные и транзакции, опубликованные у издателя, среди подписчиков. Распространитель также хранит историческую информацию о подписках. Чаще всего издатель и распространитель находятся на одном компьютере. В то же время при значительной нагрузке некоторые типы репликаций только выиграют, если распространитель будет перенесен на отдельный сервер, т.е. отделен от издателя. Ядром распространителя является база данных распространения — хранилище исторической информации и метаданных, используемых репликациями моментальных снимков и транзакций. Издатель может использовать только одну базу данных распространения. Распространитель может содержать несколько баз данных распространения, ориентированных на конкретных издателей или их группы.

Модель с централизованным издателем

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

Модель с централизованным подписчиком

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

Модель с переизданиями

Переизданием называют ситуацию, когда подписчик одновременно выступает издателем для других подписчиков, публикуя для них статьи, полученные от главного издателя. Эта модель обычно используется для масштабирования решений репликации. Например, в организационной структуре может существовать единый центральный офис, который распространяет информацию в свои региональные офисы, которые, в свою очередь, выступают издателями для своих местных подписчиков. Чтобы модель с переизданиями хорошо работала, нужно четко представлять себе все потоки данных, а также все серверы, порождающие данные или являющиеся их авторизованным источником. Это может привести к созданию полноценной модели одноранговой репликации. Если вы не имеете такого контроля над потоками данных, то дублирующие друг друга данные могут вводиться в разных региональных центрах; также могут образоваться своеобразные “черные дыры”, поглощающие информацию, но не переиздающие ее для конечных потребителей.

Одноранговая модель

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

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

?               Когда данные с одним и тем же первичным ключом одновременно вставляются на разных узлах, после чего синхронизируются с другими серверами. В этом случае возникает коллизия первичных ключей.

?               Когда данные обновляются на одном узле и одновременно удаляются на другом.

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

Статья

Статьей называют минимальную единицу публикации. Статья может представлять собой элемент:

?               таблиц;

?               разделенных таблиц;

?               хранимых процедур (CLR и T-SQL);

?               выполнений хранимых процедур (CLR и T-SQL);

?               представлений;

?               индексированных представлений;

?               индексированных представлений в форме таблиц;

?               пользовательских типов (CLR);

?               пользовательских функций (CLR и T-SQL);

?               псевдонимов типов данных;

?               полнотекстовых индексов;

?               объектов схемы (ограничений, индексов, триггеров, расширенных свойств, сопоставлений и т.п.).

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

?               Повышение производительности. Независимые параметры агента в репликации транзакций могут создать два или более параллельных потока данных, направленных к подписчику.

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

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

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

Принудительная подписка

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

Принудительные подписки обычно используют в следующих ситуациях.

?               Когда число подписчиков относительно невелико.

?               Когда репликация выполняется в пределах локальной сети или интрасети — принудительные подписки не работают через Интернет.

?               Когда необходима централизация управления репликацией.

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

Подписка по запросу

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

?               Когда число подписчиков сравнительно велико.

?               Когда выполняются репликации через ненадежные коммуникационные каналы (в том числе через Интернет), а также в автономном режиме работы подписчиков.

?               Нет необходимости в централизованном узле управления.

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

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии