Распределённые
данные
Способы
распределения данных
Репликация
Агенты
репликации
Репликация
слиянием
Модели
репликации
Вопросы
для повторения
Распределённые данные
До сих пор, мы обсуждали работу единственного сервера баз
данных, который обслуживает запросы, преимущественно, клиентов
локальной сети. Однако, не всегда такой подход бывает удобен
или достаточен для поддержания приемлемого для пользователей
режима работы с данными. Если пользователи информации удалены
от локальной сети, но им требуется сопоставимый по времени
отклика доступ к данным, описываемыми ранее методами его не
обеспечить. Для решения этой задачи, MS SQL Server 7.0 оснащён
механизмами репликации и распределения транзакций. Создание и
поддержка локальной для удалённых клиентов копии базы данных,
которая может отражать содержание оригинальной базы, как в
реальном времени, так и с заданной задержкой синхронизации,
решается этими двумя механизмами и образует среду
распределения данных. Таким образом, можно не только
приблизить данные к пользователю, но и обеспечить автономность
серверов, разделить обработку одних и тех же данных из OLTP и
OLAP приложений, а также уменьшить число конфликтов и
блокировок.
Если выбирается механизм репликации, это
подразумевает создание копий содержимого базы данных, как
правило, на разных серверах. Данные синхронизируются в
заданном, широком временном диапазоне. Поддерживается
автономность серверов, расширяя тем самым возможности
масштабирования приложения в целом, и предоставляя возможность
последовательно/постепенно вводить в эксплуатацию новые
сервера/узлы.
Если выбирается механизм распределённых
транзакций, это позволяет синхронизировать в реальном времени
данные на всех серверах среды распределения данных, так, что
они будут всегда идентичны. Требуется поддержка постоянной
готовности и доступности участвующих в обслуживании
распределённых транзакций серверов, не допускающая сбоев
транзакций на любом из серверов, иначе эта транзакция не
сможет быть применена на остальных серверах среды
распределения данных. Такие жёсткие требования существенно
ограничивают гибкость и масштабируемость применения механизма
распределения транзакций.
Принимая решение о том, какой из
имеющихся механизмов распределения данных для Вас наиболее
приемлем, нужно решить, допустимо ли расхождение данных на
разных серверах, устраняемые системой с заданной задержкой.
Для этого, Вы должны составить себе представление о допустимом
уровне автономности серверов, который будет определять, через
какие временные интервалы каждый сервер среды будет обращаться
к источнику данных за обновлённой информацией. Необходимо
также учитывать, что механизмы распределения данных основаны
на транзакциях, которые гарантируют, что любое действие будет
выполнено полностью или в случае невозможность довести его до
конца, произойдёт откат предполагаемых в этом действии
изменений. Причём, имеющаяся в репликации задержка со времени
первоначального обновления не повлияет на согласованность
данных.
Способы распределения данных
Разные способы распределения данных отличаются по степени
автономности, которая зависит от продолжительности задержки
синхронизации данных. Рассмотрим далее эти способы в порядке
увеличения автономности и времени задержки
синхронизации.
Минимальная задержка и автономность у
распределённых транзакций. Этот способ распределения данных
характерен тем, что служба Microsoft Distributed Transaction
Coordinator (DTC) обеспечивает синхронизацию данных в реальном
времени используя механизмы протокола двухфазной фиксации.
Т.о. распределённая транзакция завершается одновременно на
всех задействованных в ней серверах/узлах, а данные на этих
узлах будут всегда синхронны.
Способ transactional
replication (репликация транзакций), при сохранении порядка
исполнения транзакций, реплицирует только изменённые данные,
что гарантирует отсутствие конфликтов.
Следующий по нашему
порядку способ, это репликация транзакций с обновлением на
подписчике. Как следует из названия, допускаются изменения
данных не только на сервере - источнике изменений, но и на
серверах, подписанных на репликацию, т.е. локальных. За счёт
того, что DTC автоматически обновляет, как локальные, так и
данные на источнике, конфликты также не возникают. Этот
способ, своеобразный гибрид технологии распределения
транзакций и репликации, в привычном смысле. Репликация
происходит по мере обновления данных, что влияет на время
согласования данных.
Snapshot replication (репликация
моментальных снимков) представляет следующий уровень
автономности. Здесь данные на подписчике обновляются оптом,
изменённые и не изменённые. Передача снимков осуществляется
вручную или с заданной периодичностью, что и определяет
период, когда данные будут синхронизированы.
Другим
симбиозом уже представленных способов является репликация
моментальных снимков с обновлением. Сама репликация
осуществляется почти так же, как и репликация транзакций с
обновлением на подписчике. Отличие в том, что эта репликация
выполняется только периодически, что определяет другой уровень
автономности.
Marge replication (репликация слиянием)
допускает обновление на локальных узлах, которые периодически
обновляют сервер-издатель. Здесь возможны конфликты, но они
легко разрешимы, причём, поддержка транзакций хоть и
поддерживается, но порядка в этом никакого нет, а
синхронизация выполняется только копий.
Репликация
Издатель «publisher» содержит исходные базы данных, готовит
данные к репликации и отправляет изменения
подписчикам.
Дистрибутор «distributor» получает все
изменения, связанные с публикуемыми данными, сохраняет эти
изменения, а затем с заданным интервалом пересылает их
соответствующим подписчикам. Хотя издатель и дистрибутор могут
находиться на одном и том же сервере, лучше их размещать на
отдельных компьютерах. Один дистрибутор может обслуживать
несколько издателей.
Подписчик «subscriber» хранит копию
данных и получает изменения, внесенные в публикацию.
В
схеме Издатель - Подписчик, публикуемые данные бывают двух
типов: статьи и публикации. Публикация «publication» может
содержать одну или несколько статей (отдельных таблиц или
хранимых процедур). Поскольку все статьи в составе публикации
синхронизируются одновременно, ссылочная целостность
гарантируется. Отметим следующие свойства публикации:
публикация служит основой подписки, которая включает все
статьи данной публикации; на основе содержимого базы данных
пользователя можно создать одну или несколько публикаций.
В
репликации Статья «article» определяется следующим образом:
она содержит одну таблицу или подмножество данных таблицы;
статья является частью публикации. С помощью Enterprise
Manager можно подписаться на публикацию, но непосредственно на
статью подписаться нельзя.
Части таблицы можно публиковать
в виде статей. Этот процесс называется фильтрацией данных.
Средство фильтрации данных позволяет избежать конфликтов
репликации в случае, когда обновлять данные разрешено
нескольким узлам. Таблицы можно фильтровать по вертикали, по
горизонтали или одновременно и по вертикали, и по горизонтали.
Каждый экземпляр отфильтрованной таблицы представляет
отдельную статью. Вертикальный фильтр определяет некоторое
подмножество столбцов таблицы. Подписчику доставляются только
реплицируемые столбцы. Например, с помощью вертикального
фильтра можно публиковать всю таблицу, кроме определённого
столбца. Горизонтальный фильтр определяет некоторое
подмножество строк в таблице. Подписчик будет получать лишь
это подмножество строк. Например, можно фильтровать записи о
заказах по регионам и публиковать их в соответствующих
регионах. Для реструктуризации данных можно прибегнуть и к
другим способам изменения схемы базы данных. Разбиение строк
означает физическое выделение горизонтального подмножества
данных в отдельную таблицу. Например, можно разбить таблицу
заказчиков на отдельные таблицы по каждому региону.
Фрагментация столбцов означает физическое выделение
вертикального подмножества данных в отдельную таблицу.
Например, можно фрагментировать таблицу отрудников по
вертикали таким образом, чтобы в одной таблице оставить
столбцы имени, должности и номера комнаты, а в другой —
конфиденциальные сведения, такие как дата рождения и
оклад.
Существует два вида подписки на публикацию: подписка
по запросу pull subscription и принудительная подписка push
subscription. Принудительную подписку можно оформить в тот
момент, когда, вы создаете или редактируете публикацию на
издателе. Применение принудительной подписки позволяет
централизованно управлять подпиской. Кроме того,
принудительная подписка определяется издателем, а для каждой
публикации можно назначить сразу несколько подписчиков.
Принудительная подписка обычно используется в приложениях,
которые должны сразу рассылать подписчикам изменения, как
только те происходят. Наиболее целесообразна принудительная
подписка на публикации, требующие более надежной защиты, в
случаях, когда повышение накладных расходов на ресурсы
процессора дистрибутора не отражается на производительности.
Подписку по запросу можно также оформить на сервере
подписчика. Подписка по запросу инициируется подписчиком и,
чтобы можно было подписаться, для публикации должна быть
разрешена подписка по запросу, подписчик должен быть
зарегистрирован или для публикации разрешена анонимная
подписка на публикацию. Кроме того, оформить подписку по
запросу может только подписчик сервера. Только системный
администратор или владелец базы данных подписчика решает,
какие публикации и когда следует получать. Подписка по запросу
наиболее удобна для публикаций, которые выдвигают умеренные
требования к безопасности и могут поддерживать большое число
подписчиков — например, в Интернете. Дистрибутор должен иметь
достаточно ресурсов для поддержки некоторого числа
подписчиков, а подписчики должны иметь достаточно ресурсов для
проведения репликации.
Агенты репликации
Чтобы можно было проводить репликацию, необходимо сначала
синхронизировать исходные таблицы данных и таблицы назначения.
Агент создания моментальных снимков (Snapshot) используется
при проведении начальной синхронизации во всех методах
репликации. Этот агент готовит схему и содержимое публикуемых
таблиц и хранимых процедур, а затем сохраняет файлы на
дистрибуторе. Агент распределения (Distribution) применяет к
подписчикам полученные от дистрибутора моментальные снимки
данных. Кроме того, этот агент применяет к подписчикам
транзакции базы данных Distribution. Средства репликации
просматривают журнал транзакций каждой базы данных, для
которой назначена репликация транзакций, и ищут транзакции,
подлежащие репликации. Агент чтения журнала транзакций (Log
Reader) копирует транзакции, помеченные для репликации в
журнале транзакций издателя, в базу данных Distribution, где
они остаются до тех пор, пока их не удастся распределить по
соответствующим подписчикам и применить к их базам данных.
Агент слияния (Merge) объединяет изменения данных из
нескольких узлов, которые произошли с момента получения
первоначального моментального снимка.
Поддерживается три
типа репликации: репликация моментальных снимков, репликация
транзакций и репликация слиянием. Репликация каждого типа
применяется к одной публикации. В одной базе данных можно
использовать несколько типов репликации.
Репликация
моментальных снимков представляет собой периодическую передачу
подписчикам новых моментальных снимков данных; это самый
простой тип репликации с точки зрения настройки и
сопровождения. Репликацию моментальных снимков целесообразно
использовать в среде, характеризуемой следующими условиями:
подписчикам требуются данные, доступные только для чтения;
допускается большая задержка, поскольку данные обычно
обновляются лишь периодически; подписчики могут поддерживать
автономию узлов. Для реплицируемых таблиц в системе с
репликацией моментальных снимков первичные ключи не требуются.
В процессе репликации транзакций изменения, произошедшие в
исходной базе данных, реплицируются по месту назначения.
Обычно репликация производится с минимальной задержкой.
Репликацию транзакций можно использовать в условиях, когда
подписчики должны получать измененные данные сразу после
обновления, с минимальной задержкой.
Прежде чем начнется
репликация транзакций, агент создания моментальных снимков
делает первоначальный моментальный снимок. Можно задать
частоту обновления этого моментального снимка. В журнале
транзакций отслеживаются изменения таблиц, помеченных к
репликации.
В ходе репликации слиянием узлам разрешается
автономно друг от друга вносить изменения в реплицируемые
данные. Впоследствии изменения, полученные со всех узлов,
объединяются - периодически или по требованию. Репликация
слиянием не обеспечивает согласованность транзакций, но
гарантирует, что все узлы в итоге придут к одному
результирующему набору. Репликацию слиянием можно использовать
для фильтрации или разбиения данных. Прежде чем начнется
репликация слиянием, агент создания моментальных снимков
делает первоначальный моментальный снимок. Можно задать
частоту обновления этого моментального снимка. В ходе
репликации слиянием агент создания моментальных снимков
копирует некоторые файлы вдобавок к тем, которые были
скопированы во время репликации моментальных снимков и
транзакций. Все изменения агент сохраняет в рабочей папке
службы дистрибуции.
Выбор типа репликации определяет,
какие используются агенты и ресурсы. Агент создания
моментальных снимков читает содержимое базы данных и создает
файлы моментальных снимков в рабочей папке на дистрибуторе. В
ходе репликации моментальных снимков сервер сохраняет в базе
данных Distribution сведения о состоянии, но не сохраняет
данные. В случае принудительной подписки агент распределения
работает на дистрибуторе. Этот агент применяет к подписчику
моментальные снимки данных, взятые из рабочей папки службы
дистрибуции. В случае подписки по запросу агент распределения
работает на сервере-подписчике. Репликация транзакций обычно
начинается с разовой процедуры репликации моментального
снимка, необходимой для синхронизации данных; при этом может
использоваться как принудительная подписка, так и подписка по
запросу. Затем в ходе репликации транзакций агент чтения
журнала транзакций периодически считывает содержимое журнала
транзакций сервера-издателя и сохраняет эти сведения в базе
данных Distribution. Агент распределения применяет изменения к
серверам-подписчикам. Агент слияния проводит репликацию
слиянием на сервере-подписчике, используя файлы, скопированные
агентом создания моментальных снимков. В случае принудительной
подписки агент слияния работает на дистрибуторе. В случае
подписки по запросу агент слияния работает на
сервере-подписчике. В ходе репликации слиянием сервер
сохраняет в базе данных Distribution сведения о состоянии, но
не сохраняет данные. Агент слияния получает от издателя
изменения и применяет их к серверам-подписчикам. Затем агент
слияния собирает изменения со всех подписчиков, применяет их к
серверу-издателю и разрешает конфликты обновления, если они
возникли.
Репликация слиянием
В ходе репликации слиянием в схему вносятся изменения в
целях предотвращения или разрешения конфликтов. Чтобы
репликация слиянием протекала нормально, SQL Server вносит в
схему публикуемой базы данных три важных изменения:
-
Сервер выбирает уникальное поле для каждой строки
реплицируемой таблицы. Это позволяет однозначно
идентифицировать строку среди нескольких копий таблицы.
-
В схему добавляется несколько системных таблиц для поддержки
отслеживания данных, эффективной синхронизации, а также
обнаружения и разрешения конфликтов и составления отчетов о
них.
- Сервер создает триггеры для таблиц издателя и
подписчика, которые отслеживают изменения данных в каждой
строке, а если необходимо, то и в каждом столбце. Эти триггеры
собирают изменения, внесенные в таблицу, и записывают их в
системные таблицы слияния.
Поскольку сервер поддерживает в базовой таблице несколько
триггеров одного типа, триггеры репликации слиянием не мешают
работе триггеров, определяемых приложением, т.е. и те, и
другие могут сосуществовать одновременно.
Замечание:
Репликация слиянием не поддерживает вертикальную фильтрацию.
Поскольку репликация данного типа допускает независимые
обновления, возможны конфликты. Репликация слиянием
обрабатывает их с помощью механизма разрешения конфликтов,
основанного на приоритетах. Агент слияния отслеживает каждое
обновление строки. Протокол всех изменений строки образует
описание происхождения строки. Когда агент слияния, объединяя
изменения, встречает строку, с которой могло произойти
несколько изменений, он изучает происхождение этой строки и
пытается выяснить, нет ли конфликта. Конфликты могут
выявляться на уровне строки или на уровне столбца. Агент
слияния сравнивает поступившие значения данных с текущими, и
все конфликты между новыми и старыми значениями автоматически
разрешаются на основе установленных приоритетов. Значения
данных реплицируются в другие узлы только при выполнении
синхронизации; процедуры синхронизации могут повторяться с
интервалом в несколько минут, дней и даже недель. Вы можете
изменить триггеры и определить свой собственный алгоритм
разрешения конфликтов.
Модели репликации
В этой шпаргалке мы рассмотрим модели репликации,
реализуемые на практике, и соответствие этих моделей типам
репликации (репликация моментальных снимков, репликация
транзакций, репликация слиянием). Эти основные модели
репликации могут служить примером того, как распределяются
роли серверов во время репликации.
Центральный
издатель-дистрибутор - в данной модели (Central
Publisher/Distributor), принимается сервером по умолчанию)
один сервер определен как издатель-дистрибутор
(Publisher/Distributor). Издатель-дистрибутор публикует и
распределяет данные по серверам, описанным как подписчики; их
число может быть любым. Издатель и дистрибутор могут
располагаться на одном сервере или на разных. В любом случае
сервер, отвечающий за публикацию, является главным владельцем
или источником всех реплицируемых данных. Обычно на сервере,
занимающемся дистрибуцией, хранятся данные перед их
публикацией на серверах, оформивших подписку. Предполагается,
что данные, полученные в узлах-подписчиках, доступны только
для чтения. Администраторы должны следить за тем, чтобы в
отношении таблиц подписчика действовало лишь разрешение на
оператор SELECT. Если издатель и дистрибутор установлены на
разных серверах, то такая модель позволяет передать
значительную часть работы по репликации от издателя к
дистрибутору.
Центральный подписчик, несколько издателей -
в данной модели (Central Subscriber/Multiple Publisher)
несколько издателей реплицируют данные для одного подписчика.
Эта модель позволяет сосредоточить данные в центральном узле,
оставляя в локальном узле только локальные данные. В данном
случае несколько издателей осуществляют запись в одну и ту же
таблицу подписки, поэтому важно проследить за тем, чтобы у
каждой порции данных был уникальный локальный владелец и ее не
мог затереть никакой другой издатель. В этих целях применяется
фильтрация данных по горизонтали.
Несколько издателей,
несколько подписчиков В данной модели (Multiple
Publisher/Multiple Subscriber) каждый из серверов публикации и
серверов подписки в состоянии играть две роли. Эта модель
представляет наиболее близкое приближение к полностью
распределенной обработке данных. Необходимо соблюдать
осторожность при конструировании схемы и типов обновления,
чтобы обеспечить адекватный уровень согласования данных по
всем узлам.
Возможно применение комбинированных моделей и
типов репликации. Модель репликации представляет собой
физическое воплощение схемы репликации. Практически все время
в процессе разработки уходит на проектирование модели
репликации. Тип репликации (моментальные снимки, транзакции
или слияние) определяет функциональные возможности, доступные
для сопровождения реплицируемых данных. Любую модель можно
использовать в репликации любого типа. Обычно и модель, и тип
выбираются одновременно; модель не обусловливает какой-то
конкретный тип, и наоборот. В одной базе данных можно создать
множество публикаций с разными типами репликации. Например, в
базе данных компании одна публикация может включать
инвентарные данные и использовать репликацию транзакций с
обновлением подписчиков, а другая публикация будет
представлять собой список заказчиков, образуемый с помощью
репликации слиянием, чтобы его можно было обновлять во всех
узлах.
Вопросы для повторения
ВОПРОС
Ваша компания испытывает трудности,
связанными с конфликтами в системе. Они возникают, когда отдел
сбыта и отдел маркетинга занимаются составлением ежедневных
отчетов, а отдел обработки заказов выполняет текущие операции
обработки заказов. Руководство компании решило организовать
репликацию данных. Какие свойства и характеристики следует
учесть при выборе метода копирования корпоративных
данных?
ОТВЕТ
Необходимо как минимум принять во
внимание возможность согласования транзакций, величину
задержки, степень автономии узлов, уровни безопасности,
имеющиеся источники данных, частоту обновления данных,
производительность, возможности администрирования и
потребность в обновлении подписчиков.
ВОПРОС
Ваша
компания является крупнейшим производителем, имеет множество
филиалов по всему миру и собирается распределять данные путем
репликации. Вам нужно разработать стратегию репликации. Ваша
цель - обеспечить ежедневное поступление данных о продажах из
всех филиалов в штаб-квартиру компании. Поскольку большинство
филиалов являются удаленными, вас беспокоят высокие расходы на
междугородную связь. Какую модель репликации следовало бы
использовать? Почему?
ОТВЕТ
Наилучший подход в
данных условиях состоял бы в использовании комбинации двух
моделей репликации. В каждом регионе можно иметь центрального
подписчика, который играл бы роль удаленного распределителя и
по ночам реплицировал бы ежедневные данные о продажах в
головной офис компании. Использование региональных удаленных
распределителей позволит свести к минимуму расходы на
междугородную связь.