Лекции по АБД. Лекция 7. данные доступны пользователям в нужном месте и в нужное время
 Скачать 232.97 Kb.
|
|
Репликации Для многих предприятий и организаций важно, чтобы данные, используе- мые различными приложениями, были бы доступны в любом месте и в любое время. Подобная среда для данных может быть предоставлена несколькими ба- зами данных, которые включают множество копий одной и той же информации. Переезжающие с места на место менеджеры представляют хороший при- мер того, как используется среда распределенных данных. В течение дня прода- вец обычно использует дорожный компьютер для запроса всей необходимой ин- формации из базы данных (например, цены и наличие товара) для информирова- ния на месте покупателей. Позже, в номере отеля, продавец снова использует дорожный компьютер - на этот раз для пересылки данных о проданных товарах в центральный офис предприятия. Пример иллюстрирует тот факт, что среда распределенных данных имеет несколько преимуществ по сравнению с централизованной обработкой данных: • данные доступны пользователям в нужном месте и в нужное время; • локальный пользователь может автономно оперировать данными; • система сокращает сетевой трафик; • технологический безостановочный процесс существенно дешевле. С другой стороны, среда распределенных данных является гораздо более сложной системой, чем соответствующая централизованная модель, и поэтому требует больше сил на планирование и администрирование. Методы распределения данных Существуют два основных метода распределения данных на множество серверов базы данных – это распределенные транзакции и репликация данных. Распределенная транзакция - это транзакция, где все изменения во всех местах, где хранятся распределенные данные, собираются вместе и выполняются синхронно. Распределенные системы баз данных используют метод, называемый двухфазовым подтверждением, для реализации распределенных транзакций. Каждая база данных, вовлеченная в распределенную транзакцию, имеет собственную технику восстановления, которая используется в случае ошибки. Менеджер глобального восстановления (называемый координатором) координи- рует обе фазы распределенного процесса. На первой фазе этого процесса координатор проверяет, все ли участвую- щие элементы готовы выполнять их часть распределенной транзакции. Вторая фаза состоит из фактического выполнения транзакции на всех участвующих эле- ментах. В течение этого процесса любая ошибка на любом элементе приводит к тому, что координатор останавливает транзакцию. В этом случае он отправляет сообщение каждому менеджеру локального восстановления, чтобы он отменил ту часть транзакции, которая уже была выполнена на этом элементе. Microsoft Distributed Transaction Coordinator (DTC) поддерживает распре- деленные транзакции с использованием двухфазового подтверждения. DTC – компонент Microsoft Windows, предназначенный для координации изменения данных на двух или более сетевых компьютерных системах. Он осно- ван на технологии COM+ и включает в себя: менеджер транзакций; журнал тран- закций; прокси (реализует интерфейсы DTC); утилиты администрирования и за- головочные файлы API. Каждый компьютер, участвующий в выполнении распределённых транзак- ций, имеет локальный менеджер транзакций, который взаимодействует с прило- жениями и локальными менеджерами ресурсов (такими, как базы данных, фай- ловые системы, системы хранения документов, очереди сообщений). При полу- чении запроса на выполнение транзакции между парами систем устанавлива- ются отношения вышестоящая - подчинённая. Каждая система может иметь не- сколько подчинённых систем, но не более одной вышестоящей. Это отношение справедливо для каждой конкретной транзакции, при выполнении других тран- закций роли менеджеров могут меняться. При запросе фиксации или отката транзакции менеджером транзакций вы- полняется двухфазный протокол фиксации. Во время первой фазы менеджеру ресурсов посылается запрос на подготовку к завершению, во время второй - на фиксацию или откат транзакции. По дереву, образованному вышестоящими и подчинёнными системами, рассылаются сообщения для подготовки к заверше- нию, фиксации или отката. Любой узел дерева может прервать транзакцию до подтверждения подготовки к завершению. После того, как узел подтвердил под- готовку, он остаётся в этом состоянии до фиксации или отката транзакции вы- шестоящим узлом. В случае сбоя и перезагрузки компьютера менеджер транзак- ций запрашивает вышестоящий узел о дальнейшей судьбе подготовленных к за- вершению транзакций. Репликация (replication) – это механизм синхронизации содержимого не- скольких копий базы данных. Это процесс копирования измененных данных из одного источника на другой (или на множество других) и наоборот. При репли- кации изменения, сделанные в одной копии базы данных, могут быть распро- странены в другие копии. Репликация делается автоматически, администратору не надо делать вруч- ную экспорт, а потом импорт данных. Другими словами, это синхронизация между несколькими серверами. Например, есть сервер с БД сайта, к которому в минуту обращаются 5000 посе- тителей, и этот сервер заметно подтормаживает. Тогда рекомендуется одну и туже БД расположить на двух серверах чтобы посетителей поделить - по 2500 на каждый сервер. А для того чтобы посетители получали одну и туже информацию с разных серверов их надо синхронизировать, вот такая синхронизация и назы- вается репликацией. В течение процесса репликации данных копии данных распределяются от исходной базы данных к одной или более целевым базам данных, размещенным на отдельных компьютерах. По этой причине репликация данных отличается от распределенных транзакций в двух аспектах, а именно: промежутком времени и задержкой по времени. В отличие от метода распределенных транзакций, где все данные являются одними и теми же на всех участвующих элементах, репликация данных позво- ляет элементам иметь различные данные в одно и то же время. Кроме того, ре- пликация данных является асинхронным процессом. Это означает, что суще- ствует некоторая задержка по времени, когда все копии данных становятся оди- наковыми на всех участвующих в процессе элементах. Эта задержка может из- меняться в диапазоне от единиц секунд до нескольких дней или недель. Выбор метода распределения данных Репликация данных в большинстве случаев является лучшим решением, чем использование распределенных транзакций, потому что она дешевле и надежнее. Эксперименты с двухфазовым подтверждением транзакций показали, что администрирование становится более сложным при увеличении участвую- щих в этом процессе элементов. Кроме того, увеличение участвующих элемен- тов уменьшает надежность, потому что вероятность того, что локальная часть распределенной транзакции завершится со сбоем, увеличивается при увеличении количества узлов. Если один локальный элемент дает сбой, то вся распределен- ная транзакция также даст сбой. Другой причиной использования репликации данных вместо централиза- ции данных является производительность: пользователи элемента с репликацией данных, имеют повышенную производительность, потому что у них есть воз- можность получать доступ к данным локально, а не при использовании сети для соединения с центральным сервером базы данных. Общие сведения о репликации Вообще, репликация основывается на двух различных концепциях: ис- пользование протокола транзакций и использование триггеров. Database Engine хранит все значения измененных строк (значения как "до", так и "после") в системных файлах, называемых протоколами транзакций. Если для выбранных строк нужно выполнить репликацию, система запускает новый процесс, который читает данные из протокола транзакций и отправляет их одной или более целевым базам данных. Второй метод основан на триггерах. Изменение таблицы, содержащей дан- ные, для которых должна быть выполнена репликация, вызывает соответствую- щий триггер, который по порядку создает новую таблицу с данными и запускает процесс репликации. Обе концепции имеют как преимущества, так и недостатки. Репликация, основанная на протоколе, характеризуется улучшенной производительностью, поскольку процесс, который читает данные из протокола транзакций, выполня- ется асинхронно и оказывает очень небольшое влияние на производительность всей системы. С другой стороны, реализация репликации, основанной на прото- коле транзакций, является весьма сложной для компаний, создающих системы баз данных, потому что система базы данных должна не только управлять допол- нительными процессами и буферизацией, но и разрешать проблемы одновремен- ного доступа между системой и процессами репликации, которые обращаются к протоколу транзакций. Database Engine использует обе концепции: метод протокола транзакции для процесса репликации на основе транзакций и триггеры для слияния обрабо- танных репликаций. Издатели, распространители и подписчики Репликация Database Engine основывается на понятии издатель-подпис- чик. Оно описывает различные роли, которые могут играть серверы в процессе репликации. Один или более серверов публикуют данные, на которые могут под- писываться другие серверы. Между ними существует распространитель, кото- рый сохраняет изменения и передает их дальше подписчикам. Следовательно, отдельный сервер может иметь три роли в технологии репликации. ♦ Издатель (или публикующий сервер). Поддерживает свои исходные базы данных, делает данные доступными для репликации и отправляет изменен- ные данные распространителю. ♦ Распространитель (или распределяющий сервер). Получает от изда- теля все изменения для данных, подлежащих репликации, сохраняет и отправ- ляет их соответствующим подписчикам. ♦ Подписчик (или получающий сервер). Получает и сохраняет опубли- кованные данные. Сервер базы данных может играть несколько ролей в процессе репликации. Например, сервер в одно и то же время может работать как издатель и как рас- пространитель. Этот сценарий подходит для случая с небольшими репликациями и с небольшим количеством подписчиков. Если же существует множество под- писчиков для информации издателя, то распространитель должен размещаться на собственном сервере. Допустимы репликации только для пользовательских баз данных. Единица публикуемых данных называется публикацией. Статья содержит данные из таблицы и/или одной или более хранимых процедур. Таблица статьи может быть целой таблицей или подмножеством данных таблицы. Хранимая процедура статьи может содержать одну или более хранимых процедур, которые существуют в базе данных на момент публикации. Публикация содержит одну или более статей. Каждая публикация может содержать данные только из одной базы данных. Публикация является основой подписки. Это означает, что нельзя подпи- сываться напрямую к статье, потому что статья является частью публикации. Фильтр является процессом, который ограничивает информацию, создавая подмножество. Поэтому публикация содержит один или более следующих эле- ментов, которые задают типы статей таблицы: таблица, вертикальный фильтр, горизонтальный фильтр и комбинация вертикальных и горизонтальных филь- тров. Вертикальный фильтр содержит подмножество столбцов таблицы. Гори- зонтальный фильтр содержит подмножество строк таблицы. Подписка может быть инициализирована двумя различными спосо- бами - через принудительную подписку и через подписку по запросу. При принудительной подписке все управление созданными подписками выполняется издателем в процессе определения публикации. Принудительные подписки упрощают и централизуют управление, потому что обычный сценарий репликации содержит одного издателя и множество подписчиков. Преимуще- ством принудительной подписки является высокий уровень безопасности, по- тому что процесс инициализации управляется из одного места. С другой сто- роны, производительность распространителя может пострадать, потому что пол- ное распространение подписок выполняется немедленно. При подписке по запросу подписчик инициализирует подписку. Подписка по запросу является более избирательной, чем принудительная подписка, потому что подписчик может выбирать публикации для подписки. В отличие от прину- дительной подписки подписка по запросу должна быть использована для публи- каций с низким уровнем секретности и большим количеством подписчиков. Загрузка данных через Интернет является типичным примером подписки по запросу. Типы репликации Database Engine предоставляет следующие типы репликации: репликация транзакций, репликация мгновенного снимка, репликация слияния и одноранго- вая репликация. Репликация транзакций. Здесь для репликации данных используется про- токол транзакций системы. Все транзакции, которые содержат данные, подлежа- щие репликации, отмечаются как транзакции для репликации. Компонент с име- нем Log Reader Agent отыскивает отмеченные транзакции и копирует их из про- токола транзакций издателя в базу данных distribution. Другой компо- нент - Distribution Agent - перемещает транзакции подписчику, где они применя- ются для целевых таблиц в подписанных базах данных. Все таблицы, опубликованные с использованием репликации транзакций, должны явно содержать первичный ключ. Первичный ключ требуется для уни- кальной идентификации строк в опубликованной таблице, потому что строка яв- ляется единицей перемещения в репликации транзакций. Репликация транзакций может выполнять репликацию таблиц (или части таблиц) и одной или более хранимых процедур. Использование хранимых про- цедур в репликации транзакций повышает производительность, потому что объем данных, пересылаемых через сеть, обычно бывает значительно меньше. Вместо репликации данных подписчику пересылаются только хранимые проце- дуры, где они и выполняются. Можно сконфигурировать время задержки син- хронизации между издателем с одной стороны и подписчиком с другой стороны в процессе выполнения репликации транзакций. Все эти изменения распростра- няются компонентами Log Reader Agent и Distribution Agent. База данных distribution является системной базой данных, которая инстал- лируется на распределяющий сервер, когда запускается процесс репликации. Эта база данных содержит все реплицированные транзакции из публикаций и изда- телей, которые должны быть отправлены подписчикам. Это интенсивно исполь- зуется только в репликации транзакций. Прежде чем репликация транзакций может начаться, каждому подписчику должна быть направлена копия полной базы данных. Это осуществляется при выполнении мгновенного снимка. Репликация мгновенного снимка. Это самый простой тип репликации копи- рует опубликованные данные от издателя всем подписчикам. Различием между репликацией мгновенного снимка и репликацией транзакций является то, что в первом случае подписчику пересылаются все опубликованные данные, а во вто- ром случае - только измененные данные. Репликация мгновенного снимка тесно связана с компонентом, называе- мым Snapshot Agent. Этот компонент генерирует схему и данные из опублико- ванных таблиц и сохраняет их в файлах. Схема таблицы и соответствующий файл данных создают синхронизированный набор, который представляет мгно- венный снимок таблицы в конкретный момент времени. Создает ли агент новые файлы мгновенных снимков каждый раз при его выполнении, зависит от типа репликации и выбранных опций. Репликация транзакций и репликация мгновенного снимка являются одно- направленными репликациями, это означает, что изменения реплицируемых дан- ных создаются только на публикующем сервере. Поэтому данные на всех полу- чающих серверах являются данными только для чтения за исключением тех, из- менения которых были выполнены в процессе репликации. В отличие от репликации транзакций репликация мгновенного снимка не требует для таблиц присутствия первичного ключа. Причина очевидна: едини- цей пересылки в репликации мгновенного снимка является файл мгновенной ко- пии, а не строка таблицы. Другим отличием между этими двумя типами репли- кации является задержка во времени - репликация мгновенного снимка выпол- няется периодически, что означает значительную задержку во времени, потому что все публикуемые данные (измененные и неизмененные) пересылаются от из- дателя к подписчикам. Репликация мгновенного снимка не использует напрямую базу данных distribution. Однако база данных distribution содержит информацию состояния и другие детали, которые применяются в репликации мгновенного снимка. Репликация слияния. В репликации транзакций и в репликации мгновен- ного снимка издатель отправляет данные, а подписчик их получает. Не суще- ствует такой возможности, чтобы подписчик отправлял реплицированные дан- ные издателю. Репликация слияния позволит издателю и подписчикам изменять реплицируемые данные. По этой причине могут возникать конфликты в процессе репликации. После создания публикации на публикующем сервере Snapshot Agent под- готавливает файлы, содержащие схему таблицы и данные, и сохраняет их в ра- бочем каталоге на существующем распределяющем элементе. В процессе слия- ния репликации база данных distribution содержит только лишь состояние про- цесса репликации. Затем используется синхронизирующее задание для другого компонента - Merge Agent, который отправляет все измененные данные на дру- гой элемент. Merge Agent может отправлять реплицированные данные как под- писчикам, так и издателям. Перед тем как стартует процесс пересылки, Merge Agent сохраняет соответствующую информацию, которая позволяет отслеживать конфликты изменений. Когда используется сценарий слияния репликаций, система выполняет три важных изменения в схеме для публикуемой базы данных: она идентифицирует уникальный столбец для каждой реплицируемой строки, добавляет несколько системных таблиц и создает триггеры таблиц, для которых выполняется репли- кация данных. Database Engine создает или находит уникальный столбец в таблице для реплицируемых данных. Если базовая таблица уже содержит столбец с типом данных uniqueidentifier и со свойством rowguidcol, то система использует этот столбец для идентификации каждой реплицируемой строки. Если в таблице не существует подобного столбца, то система добавляет столбец rowguid с типом данных uniqueidentifier и свойством rowguidcol. Столбец uniqueidentifier может содержать множество экземпляров значе- ний. Свойство rowguidcol дополнительно указывает, что значение столбца с ти- пом данных uniqueidentifier уникально идентифицирует строку в таблице. По- этому столбец с типом данных uniqueidentifier со свойством rowguidcol содержит уникальное значение для каждой строки среди всех компьютеров в сети во всем мире и поэтому гарантирует уникальность реплицируемой строки среди множе- ства копий таблицы издателя и подписчиков. Добавление новых системных таблиц предоставляет способ определения и разрешения любых конфликтов обновления. Для разрешения конфликта Database Engine сохраняет все изменения, связанные с реплицируемыми дан- ными, в системных таблицах слияния msmerge_contents и msmerge_tombstone и соединяет их (используя свойство rowguid существующего столбца с типом дан- ных uniqueidentifier) с таблицей, которая содержит реплицируемые данные. Database Engine для всех таблиц, содержащих реплицируемые данные, со- здает триггеры на всех элементах для отслеживания изменения данных в каждой реплицируемой строке. Эти триггеры определяют, какие были выполнены изме- нения в таблице и записывают их в системные таблицы msmerge_contents и msmerge_tombstone. Выявление конфликта выполняется Merge Agent при использовании про- исхождения столбца в системной таблице msmerge contents. Разрешение кон- фликта может быть выполнено на основе приоритета или на основе пользова- теля. Разрешение конфликта на основе приоритета означает, что любой кон- фликт между новым и старым значениями в реплицируемой строке разрешается автоматически на основе назначенных приоритетов. Особым случаем метода на основе приоритета является метод "первый побеждает", при котором первое по времени изменение реплицируемой строки становится победителем. Метод на основе приоритета является методом по умолчанию. Метод на основе пользова- теля применяет пользовательский триггер, основанный на бизнес-правилах, определенных администратором базы данных для разрешения конфликтов. Одноранговая репликация транзакций. Она является еще одной формой ре- пликации транзакций, при которой каждый сервер в одно и то же время является издателем, распространителем и подписчиком одних и тех же данных. Иными словами, все серверы содержат одни и те же данные, но каждый сервер ответ- ственный за изменение собственной части данных. Одноранговую репликацию лучше всего объяснить примером. Предполо- жим, что компания имеет несколько офисов филиалов в различных городах, и каждый офисный сервер имеет такой же набор данных, что и все другие серверы. С другой стороны, все данные разделены на подмножества, и каждый офисный сервер может изменять только собственное подмножество данных. Когда данные изменяются на одном офисном сервере, эти изменения реплицируются на все другие серверы (подписчики) в одноранговой сети. Пользователи в каждом офисе могут читать данные без каких-либо ограничений. Преимуществами этой формы репликации являются: вся система хорошо масштабируется; вся система предоставляет высокую доступность. Система, которая поддерживает одноранговую репликацию, хорошо мас- штабируется, потому что каждый сервер обслуживает только локальных пользо- вателей. Пользователи могут изменять только те части данных, которые принад- лежат их локальному серверу. Для операций чтения все данные также хранятся локально. Высокая доступность основывается на том факте, что если один или более серверов отключаются от сети, все другие серверы могут продолжать ра- боту, поскольку все данные, необходимые им для операций чтения и записи, хра- нятся локально. Когда отключенный сервер снова включается в сеть, заново стартует процесс репликации, и сервер получает все модификации данных, ко- торые были выполнены на других сайтах. Определение конфликтов в одноранговой репликации. В случае одноран- говой репликации можено изменять данные на любом узле. Если строка изменя- ется более чем на одном узле, то это может привести к конфликту. Одноранговая репликация в SQL Server 2008 вводит опцию для возможно- сти определения конфликта в одноранговой топологии. При включенной такой опции конфликтное изменение данных трактуется как критическая ошибка, ко- торая приводит к завершению Distribution Agent. В случае конфликта сценарий остается в несогласованном состоянии, пока конфликт не будет разрешен и дан- ные не будут приведены в согласованное состояние на всех участвующих серве- рах. Можно включить определение конфликтов, используя системные проце- дуры sp_addpublication или sp_configure_peerconflictdetection. Конфликты в одноранговой репликации определяются хранимыми проце- дурами, которые применяют изменения к каждому узлу, основываясь на скрытом столбце в каждой опубликованной таблице. Этот скрытый столбец хранит иден- тификатор, комбинируемый вместе с идентификатором, который вы указываете для каждого узла, и с версией строки. Эти процедуры выполняются из Distribution Agent, они применяют операции добавления, изменения и удаления с других участников сети. Если одна из процедур определяет конфликт при чте- нии значений скрытого столбца, то она вызывает ошибку 22815. Скрытый столбец может быть доступен только тому пользователю, кото- рый соединился через Dedicated Administrator Connection. Когда появляется конфликт одноранговой репликации, то выдается преду- преждающее сообщение "Peer-to-peer conflict detection alert". Необходимо скон- фигурировать это предупреждающее сообщение так, чтобы вы были соответ- ствующим образом проинформированы при появлении конфликта. Модели репликации Типы репликации (транзакционная, мгновенный снимок, слияние и одно- ранговая) предоставляют функциональность для обработки реплицируемых дан- ных. Репликационные модели используются в компании для проектирования их собственной репликации данных. Каждая модель репликации может быть реали- зована с использованием одного или более типов репликации. Тип репликации и репликационная модель обычно определяются в одно и то же время. В зависимости от требований может быть использовано несколько моде- лей репликации. Тремя базовыми моделями репликации являются следующие: центральный издатель с распространителем; центральный подписчик с множе- ством издателей; множество издателей с множеством подписчиков. Центральный издатель с распространителем. В модели центрального из- дателя с распространителем существует один издатель и обычно один распро- странитель. Издатель создает публикации, которые распространитель распреде- ляет нескольким подписчикам. Эта модель является стандартной моделью. Если объем публикуемых данных не является слишком большим, то изда- тель и распространитель могут располагаться на одном сервере. В противном случае рекомендуется использование двух отдельных серверов для повышения производительности. Если есть большой объем публикуемых данных, то распро- странитель обычно является узким местом в процессе. Публикации, созданные в этой модели и полученные подписчиком, обычно бывают только для чтения. По этой причине в большинстве случаев ре- пликация транзакций является предпочтительным типом репликации для этой модели, хотя здесь может быть также использована и репликация мгновенного снимка. Центральный подписчик с множеством издателей. Сценарий про путеше- ствующего менеджера, который передает данные в главный офис, является ти- пичным примером центрального подписчика с множеством издателей. Данные собираются на центральном подписчике, и несколько издателей направляют туда свои данные. Для этой модели можно использовать тип репликации транзакций или сли- яния в зависимости от использования реплицируемых данных. Если издатель публикует (и, значит, изменяет) одни и те же данные для подписчика, то должна быть использована репликация слияния. Если каждый издатель имеет для пуб- ликации собственные данные, то должна быть использована репликация тран- закций или одноранговая репликация. В этом случае опубликованные таблицы будут отфильтровываться горизонтально, а каждый издатель будет исключи- тельным владельцем отдельного фрагмента таблицы. Множество издателей с множеством подписчиков. Модель репликации, в которой несколько серверов или все серверы, участвующие в репликации дан- ных, играют роль издателей, а также подписчиков, известна как модель множе- ства издателей с множеством подписчиков. В большинстве случаев эта модель включает несколько распространителей, которые обычно располагаются на каж- дом издателе. Эта модель может быть реализована только при использовании ре- пликации слияния, потому что публикации изменяются на сервере издателя. Только единственным другим способом реализации этой модели является ис- пользование распределенных транзакций с двухфазным подтверждением. Управление репликацией Все серверы, являющиеся участниками репликации, должны быть зареги- стрированы. После регистрации серверов распределяющий сервер, сервер (сер- веры) издателя и сервер (серверы) подписчика должны быть настроены. Далее описывается конфигурирование этих процессов с помощью соответствующих мастеров. Конфигурирование распределяющего и публикующего серверов. Прежде чем устанавливать публикуемые базы данных, необходимо установить распре- деляющий сервер и сконфигурировать распределяемые базы данных. Можно настроить распределяющий сервер, используя мастер Configure Distribution Wizard. Этот мастер позволяет сконфигурировать распространитель и распреде- ляемую базу данных и сделать доступным издателя (издателей). Основные функ- ции этого мастера: ♦ сконфигурировать определенный сервер в качестве распространи- теля так, чтобы его могли использовать другие издатели; ♦ сконфигурировать определенный сервер в качестве издателя так, чтобы он мог работать и как собственный распространитель; ♦ сконфигурировать определенный сервер в качестве издателя, чтобы он использовал другой сервер как распространителя. Microsoft SQL Server 2008 Express может служить подписчиком для всех типов репликации, но не может служить издателем или распространителем. |