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

0

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

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

использует три компонента:

?               агент снимков базы данных генерирует схему, данные и необходимые репликации метаданных для отслеживания процесса репликации;

?               агент распределения распространяет снимок и последующие команды;

?               агент чтения журнала читает журнал транзакций базы данных издателя.

Агент снимков

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

Агент чтения журнала

Агент чтения журнала (Log Reader Agent) ищет транзакции, которые должны быть реплицированы подписчикам. Идентификаторы этих транзакций он записывает в таблицу базы данных распространения, имеющую название msrepl_transactions. При этом все транзакции разбиваются на отдельные команды — по одной команде для каждой задействованной строки.

Рассмотрим транзакцию, обновляющую 100 строк на стороне издателя (это может быть инструкция удаления, обновления или вставки). В журнале она будет зарегистрирована как единая транзакция. После этого агент читает эту транзакцию и создает для нее запись в таблице msrepl_transactions базы данных распространения. Затем он разбивает данную транзакцию на одиночные команды, которые записывает в таблицу msrepl_commands базы распространения (о причинах такой последовательности действий вы узнаете в следующем разделе). Если инструкция достаточно большая, она может быть записана в несколько строк базы данных распространения. Все команды сохраняются в двоичном формате, но их можно прочитать с помощью хранимой процедуры sp_browsereplcmds, которую можно найти в базе распространения. По умолчанию команды, которые репликация транзакций использует для синхронизации подписчика с издателем, оформляются в виде хранимых процедур. Кроме того, у вас есть возможность хранить команды в виде отдельных инструкций SQL DML (INSERT, UPDATE и DELETE), что крайне необходимо в гетерогенной среде репликации.

Одиночной называется инструкция, которая оказывает воздействие на одну

?’На заметку строку.

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

Агент распространения

Этот агент (Distribution Agent) распространяет команды из базы данных распространения среди подписчиков. Также он удаляет из этой базы данных те команды, которые были распространены всем подписчикам и срок хранения которых вышел за пределы величины, установленной в базе.

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

Одноранговая репликация

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

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

2005

Двусторонняя репликация транзакций

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

с непосредственным обновлением

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

с очередью обновлений

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

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

?               Количество подписчиков не превосходит десяти.

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

с непосредственным обновлением и очередью восстановления

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

?               Подавляющая масса транзакций происходит у издателя.

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

?               Число подписчиков невелико.

?               Необходимо иметь возможность перевода издателя в автономный режим.

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

через Интернет

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

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

http://computer.howstuffworks.com/vpn.htm

Репликация слияния

Репликация слияния предназначена в основном для клиентов с мобильными устройствами и тех, кому часто приходится выходить в автономный режим. Изменения могут выполняться как на стороне издателя, так и на стороне подписчика. Когда запускается агент слияния (Merge Agent), эти изменения синхронизируются, после чего подписчик и издатель становятся обладателями одного и того же множества данных. В репликации слияния используются триггеры во всех таблицах, участвующих в репликации. Использование идентификаторов GUID в столбцах позволяет уникально идентифицировать все строки во всех реплицируемых таблицах. Когда изменения затрагивают одну из реплицируемых таблиц, они записываются также в таблицу метаданных, содержащую список идентификаторов GUID, соответствующих измененным строкам реплицируемых таблиц. Когда запускается агент слияния, он извлекает все идентификаторы из таблиц метаданных, соответствующие строкам, измененным на стороне издателя и подписчика. Если некоторая строка была модифицирована только на одной из сторон, она извлекается из таблицы, породившей изменения, после чего с помощью инструкций DML выполняются соответствующие вставки, обновления или удаления на противоположной стороне репликации. Если же некоторая строка была изменена на обеих сторонах репликации, то агент слияния трактует сложившуюся ситуацию как конфликт и принимает решения, основываясь на правилах, заложенных при конфигурировании агента. По умолчанию в любом конфликте преимущество отдается издателю. Чтобы изменить методику разрешения конфликтов, вы можете выбрать соответствующее правило при создании публикации. При этом используется мастер новой публикации (New Publication Wizard).

1.              Щелкните правой кнопкой мыши на публикации, которую хотите изменить, и выберите в контекстном меню пункт Properties.

2.              Выберите папку Art i с 1 е s.

3.              Щелкните на кнопке Article Properties, установите переключатель в положение Set properties of Highlighted Table article или Set Properties of All Table articles, после чего перейдите на вкладку Resolver (рис. 39.1).

Puc. 39.1. Выбор типа разрешения конфликтов в репликации слияния

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

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

?               Microsoft SQL Server Additive Coflict Resolver. Значения столбца, определенного в текстовом поле Enter information needed by resolver, суммируются для конфликтующих строк.

?               Microsoft SQL Server Averaging Coflict Resolver. Значения столбца, определенного в текстовом поле Enter information needed by resolver, усредняются для конфликтующих строк.

?               Microsoft SQL Server DATETIME (Earlier Wins) Coflict Resolver. Строка с самой ранней версией значения столбца, определенного в текстовом поле Enter information needed by resolver, выигрывает в конфликте.

?               Microsoft SQL Server DATETIME (Later Wins) Coflict Resolver. Строка с самой поздней версией значения столбца, определенного в текстовом поле Enter information needed by resolver, выигрывает в конфликте.

?               Microsoft SQL Server Download Only Conflict Resolver. В конфликте выигрывают данные, загруженные подписчиком.

?               Microsoft SQL Server Maximum Coflict Resolver. Строка с самым большим значением столбца, определенного в текстовом поле Enter information needed by resolver, выигрывает в конфликте.

?               Microsoft SQL Server Merge Text Columns Conflict Resolver. Данные в текстовом столбце, определенном в текстовом поле Enter information needed by resolver, выигрывают в конфликте.

?               Microsoft SQL Server Maximum Coflict Resolver. Строка с самым маленьким значением столбца, определенного в текстовом поле Enter information needed by resolver, выигрывает в конфликте.

?               Microsoft SQL Server Priority Conflict Resolver. В конфликте выигрывает строка с наибольшим приоритетом.

?               Microsoft SQL Server Subscriber Always Wins Conflict Resolver. В конфликте всегда побеждает подписчик.

?               Microsoft SQL Server Upload Only Conflict Resolver. В конфликте всегда побеждает строка, загруженная от подписчика.

?               Microsoft SQL Server Stored Procedure Conflict Resolver. Разрешением конфликта управляет хранимая процедура, определенная в текстовом поле Enter information needed by resolver.

Вы имеете также два дополнительных варианта.

?               Создать собственную систему разрешения конфликтов на основе хранимых процедур или компонентов СОМ.

?               Использовать расширенную логику, определенную в пространстве имен Microsoft. SqlServer. Replication. BusinessLogicSupport объектной модели RMO.

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

Репликация слияния и подписчики SQL СЕ и SQL Mobile

SQL Server 2005 позволяет пользователям мобильных систем SQL СЕ и SQL Mobile подписываться на публикации репликаций слияния. Пользователи SQL Mobile могут открыть множество подписок на разные публикации, в то время как пользователям SQL СЕ предоставляется возможность подписаться только на одну публикацию каждой из баз данных SQL СЕ.

Репликация слияния через Интернет

Новой в SQL Server 2005 является возможность выполнения репликаций слияния через защищенные подключения Интернета. При этом для синхронизации используется протокол THHPS и процесс, называемый Web-синхронизацией. У вас остается возможность размещать подписки и на серверах FTP, однако этот вариант не считается безопасным.

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

По теме:

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