Репликация данных. Типы репликаций

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

Репликация (тиражирование) - это операция пересылки информации из источника в место назначения. Тиражируя, администраторы могут защитить свою информацию или же, наоборот, сделать ее доступной для других. Например: 1)Запросы пользователей выполняются долго. Если администратор знает, что пользователям нужна информация, “возраст” которой не превышает 2-х часов, чтобы “поместить” данные в этот двухчасовой промежуток, можно воспользоваться средством тиражирования. Создать вторичный сервер, первичный сервер будет ему посылать данные каждые 30 минут, и пользователи будут обращаться к вторичному серверу, не влияя на первичный сервер. После установки и конфигурирования вторичного сервера запросы пользователей выполняются быстрее. 2)Например, есть распределенное финансовое приложение. Самые важные данные хранятся в таблице налогов, которую обслуживает центральный офис. Эта таблица большая, и часто изменяется. Администратор должен обслуживать локальные копии этой таблицы на каждом отдельном удаленном узле, его интересуют только ставки налогов его региона. Причем информация всегда должна быть свежей. Для этого используется тиражирование, причем не всех данных, а устанавливается горизонтальное тиражирование с возможностью посылать только нужную информацию на удаленные серверы. 3) Одно из преимуществ тиражирования - это то, что на сервере-подписчике тиражирование таблицы имеет свойство “только для чтения”, позволяющее защитить целостность данных.

Терминология тиражирования.

1) Немедленная гарантированная согласованность (жесткая согласованность) - изменение БД, являющейся источником, немедленно передается в базу - адресат.

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

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

3) Издатель (Published) – сервер с исходной базой данных. Издатель у любого подписчика только один. Схема множественного издания не реализуется в SQL Server.

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

Начиная с SQL Server 6.5 можно тиражировать данные в любую базу данных, имеющую драйвер ODBC, а не только в базе данных SQL-сервера.

5) Распространитель (Distributor) – сервер - получатель копии всех изменений в опубликованных данных, сохраняет изменения и открывает доступ к ним соответствующим подписчикам. Реализует распространение специальная системная база данных распространения (distribution database) и рабочий каталог распространения (distribution working folder).

6) Статья (Article)- это единый реплицируемый элемент данных.

В качестве статьи может выступать:

- таблица (при снимочной репликации может реплицироваться схема таблицы, включая триггеры, а также данные таблицы),

- набор полей таблицы (вертикальная фильтрация),

- набор записей таблицы (в случае горизонтальной фильтрации),

- набор полей и записей таблицы (в случае вертикальной и горизонтальной фильтрации),

- определение хранимой процедуры,

- запуск хранимой процедуры

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

8) Подписка – это конфигурация, определяющая способ получения подписчиком публикации от издателя. Существует два вида подписок: активные и пассивные. Подписка, которая создается и управляется на сервере-издателе, называется пассивной (её создает сервер-издатель, на любую публикацию можно подписать сразу несколько подписчиков). Подписка, созданная на подписчике, называется активной (её создает сервер-подписчик, для использования активных подписок сервер, на котором находится публикация, должен быть постоянно подключен к сети). Активные подписки бывают стандартными (регистрируются на сервере-издателе) и автономными (полностью настраиваются на сервере-подписчике, и информация на издателе не хранится). Последнее идеально подходит для подписчиков, подключающихся через Интернет. Такие подписчики могут подключаться по протоколу FTP.

Для хранения информации тиражирования SQL-сервер использует специальную БД, называемую БД распределения(distribution database)-тиражируемая информация содержится в ней до тех пор, пока не будет передана нужным подписчикам. Пользователи не имеют доступа к этой БД: она предназначена только для работы системы. В этой базе имеются таблицы 1)Msjob_commands-в каждой транзакции имеется одна или несколько команд. В этой таблице хранятся записи о таких командах (в этой таблице столбцы - номер сервера-издателя, имя опубликованной БД, идентификатор задания(job), идентификатор команды, номер статьи, реальная команда (строка)). 2) Msjob_subscriptions-используется для контроля за тем, какие статьи необходимы конкретным подписчикам (имя подписчика и его номера статей). 3)Msjobs-в этой таблице хранятся реальные транзакции. 4)Mssubscriber_info-подробная информация о заданиях тиражирования, которые должен выполнить SQL Server(тип подписчика:(0-SQL Server; 1-ODBC; идентификатор регистрации сколько времени должно пройти до момента, когда транзакции будут переданы подписчикам). 5)Mssubscriber_jobs-обеспечивает взаимосвязь между подписчиком и всеми изданиями, которые должны быть выполнены для данного подписчика. 6)Mssubscriber_status-эта таблица контролирует состояние всех изданий, выполняемых для всех подписчиков.

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

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

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

Чтобы сделать репликацию наиболее эффективной необходимо предусмотреть следующее:

1) Так как сервер-подписчик может сам тиражировать информацию, то можно построить многоуровневую архитектуру тиражирования. Многоуровневые среды могут работать быстрее, чем одноуровневые, т.к. с помощью промежуточных компьютеров многоуровневая топология может устранить необходимость в дорогостоящих протяженных соединениях.

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

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

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

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

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

7) Зеркально отображать журнал транзакций.

8) Для того, чтобы система могла работать в качестве сервера-издателя или сервера-распределителя, нужны 32 Мбайта ОЗУ, причем минимум 16 Мбайтов д.б. SQL Serverу.

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

10) Если в таблице не определен первичный ключ, SQL-сервер не может реализовать для нее средство тиражирования. Исключение есть в SQL-сервере 6.5-можно выполнить одноразовое тиражирование с помощью операции «моментального снимка»(Snapshot).

11) Рекомендуется отменять проверку ограничения «внешний ключ» добавлением опции Not For Replication в операторы Create Table и Alter Table, т.к. проверка занимает некоторое время.

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

Репликация-дублирование, тиражирование информации между серверами.

Виды реплицируемых данных(виды статей):

1. Целые БД(entire database).

2. Целые таблицы(entire tables).

3. Горизонтальные разделы(horizontal partitions) информации.

4. Вертикальные разделы(vertical partitions).

5. Выборочные виды(custom views).

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

2) При репликации целых таблиц определяется таблица, за которой производится слежение. Любые изменения, сделанные в этой таблице, пересылаются с помощью ядра репликаций(replication engine) в приемный сервер.

3) и 4) При издании горизонтальныз разделов таблиц применяется инструкция select, которая выбирает все столбцы информации, но только определенные строки репликации. Вертикальная репликация-выбор только определенных столбцов информации. Возможна комбинация вертикальных и горизонтальных разделов.

1) Можно реплицировать виды.

Если распределение и издание комбинируется на одном сервере, то на нем необходимо иметь 32 Mb ОЗУ.

Столбцы типа text или image не подлежат тиражированию; В тиражировании не могут участвовать следующие объекты: БД model, tempdb, msdb и системные таблицы master, таблицы без первичного ключа, таблицы с типом поля timestamp.

Если инициатива на тиражирование со стороны сервера публикаций - «проталкивание подписки», если со стороны сервера подписки-«вытягивание подписки».

В SQL Server различают следующие виды репликаций: снимочная репликация, транзакционная репликация, репликация сведением (слиянием).

Снимочная репликация (репликация моментальных снимков) – периодическая рассылка всей публикации серверам-подписчикам. Это самая простая в настройке и сопровождении репликация (snapshot). Моментальный снимок создается с помощью агента моментальных списков Snapshot Agent, который записывает структуру и данные. Затем моментальный снимок посылается агентом распределения Distribution Agent, который передает данные подписчикам. Подписчики получают не изменения к уже имеющимся данным, а полностью новый набор данных, который заменяет прежний. При этом старые данные уничтожаются и на их место записываются новые.

Репликация транзакций – передаются не новые таблицы целиком, а только изменения к опубликованным таблицам и команды на исполнение хранимых процедур с соответствующими параметрами. В процессе репликации участвуют агент моментальных снимков Snapshot Agent, агент распределения Distribution Agent, агент чтения журнала Log Reader Agent. Snapshot Agent используется для предоставления подписчикам начального набора данных. Log Reader Agent просматривает журнал транзакций на предмет наличия записей типа insert, update, delete, относящимся к опубликованным объектам, и осуществляет их пакетное применение к базе данных распределения. Log Reader Agent может работать постоянно или по графику, определенному администратором. Изменения хранятся в базе данных распределения до тех пор, пока Distribution Agent, ответственный за передачу данных подписчикам, не перешлет эти данные. Подписчики могут после этого вносить соответствующие изменения или осуществить перенаправленный вызов процедур в своей базе данных.

Репликация сведением (слиянием) - изменения в базе данных – источнике отслеживаются, а затем синхронизируются с базами данных издателя и подписчика. Snapshot Agent записывает структуру и данные базы данных подписчика и передает их агенту слияния (сведения) Merge Agent, который обеспечивает передачу начальных данных от Snapshot Agent и согласовывает изменения между издателем и подписчиком.

Дата добавления: 2014-10-15