Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 63)

Основные проблемы, возникающие в системах с тиражировани­ем, связаны с поддержкой согласованности состояния всех копий. Существует множество схем проведения обновления копий в РБД.

По моменту внесения изменений в реплики различают синхрон­ное и асинхронное тиражирование.

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

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

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

Асинхронное тиражирование может быть периодическим или апериодическим. Периодическое тиражирование выполняется через заданные интервалы времени. Время выполнения очередных циклов тиражирования выбирается исходя из частоты возникновения изме­нений и их интенсивности, ограничения на допустимое время рае-синхронизации состояний источника и приемника, объема данных, передаваемых в единичном цикле тиражирования, и максимально допустимой загрузки коммуникационных ресурсов и некоторых дру­гих факторов.

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

В случае синхронного тиражирования предполагается заверше­ние транзакции только после успешной модификации всех копий. Синхронное тиражирование использует механизм двухфазной фикса­ции (2РС) - Two-Phase Commit: основная система связывается с под­чиненными копиями баз данных и одновременно вносит в них из­менения, блокируя соответствующие записи. Если хотя бы одна из таких копий недоступна, изменения не выполняются. Поскольку механизм двухфазной фиксации предъявляет высокие требования к системе и снижает степень автономности узлов, то он в технологии тиражирования используется не часто.

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

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

Типичный протокол тиражирования, обеспечивающий сериализуемость по критерию полной эквивалентности копий, известен под названием Read-Once/Write-All (ROWA) - одно чтение, запись во все копии. Операция чтения в этом протоколе сводится к чтению одной какой-либо копии (вопрос о том, из какой именно копии будет выпол­няться чтение, может решаться из соображений эффективности). Каж­дая операция записи в логический элемент данных отображается на множество операций записи в физические копии этих элементов.

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

Было предложено несколько альтернативных алгоритмов, смяг­чающих требования ROWA относительно одновременности внесения изменения во все копии.

Реплики в РБД с тиражированием могут быть равноправными и неравноправными. Чаще всего они являются неравноправными. В этом случае одна из реплик считается основной. Даже При наличии нерав­ноправных реплик возможны ситуации, при которых корректировать разрешается любую реплику, но часто изменения позволено вносить только в основную реплику, а другие реплики доступны пользовате­лям только по чтению. Такая схема тиражирования называется тира­жированием из основного узла (primary site). При этом данные асинх­ронно копируются из основной в иные реплики.

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

Одной из технологий, которые могут использоваться, если изме­нения вносятся в локальные реплики, является тиражирование сли­янием (merge replication). Суть метода заключается в том, что опера­ции выполняются на удаленном компьютере, который может быть даже полностью отключен от компьютерной сети. Автономная СУБД за­писывает все операции с данными и их очередность. Затем в опреде­ленный момент автономный компьютер связывается с издателем (сер­вером, на котором корректируется БД, подлежащая дальнейшему ти­ражированию) и согласовывает с ним свои данные, пересылая издателю последовательность операций, проведенных в удаленной базе данных. При возникновении конфликтов они разрешаются с по­мощью различных алгоритмов.

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

Тиражирование слиянием обеспечивает максимальную автоном­ность удаленной базы данных.

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

Кроме того, существуют так называемые поточные модели тира­жирования (workflow). В этой модели владелец данных меняется ди­намически: данные могут обновляться на различных узлах, но в лю­бой момент времени такими полномочиями обладает только один из них. Узлы последовательно обновляют принадлежащие им данные и тиражируют изменения на всю систему.

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

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

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

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

Метод, при котором считывание данных проводится удаленными узлами из основных, называется вытягиванием изменений, а метод, заключающийся в выгрузке данных на узлы с копиями,- выталкива­нием изменений.

Обновление содержания реплик может быть обеспечено следую­щими способами:

• копированием моментального снимка базы данных;

• копированием и выполнением очереди подтвержденных изда­телем транзакций;

• копированием изменений из журнала БД.

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

В процессе тиражирования транзакций (transactional replication) от издателя к подписчикам передаются не данные, а операции над ними. Само обновление происходит на рабочей станции. Передачу транзакций можно использовать только в том случае, когда в авто­номной базе данных уже хранится копия основной БД. При исполь­зовании этой схемы периодически необходимо выполнять и полную синхронизацию данных, которая выполняется по методу тиражиро­вания моментального снимка данных. Тиражирование транзакций лучше всего использовать, когда объем базы данных велик, а опера­ций над ними выполняется немного.

В БнД вообще, а в распределенных - особенно одной из важней­ших задач является обеспечение целостности баз данных, в том чис­ле восстановление баз после их разрушения. Для этих целей исполь­зуются журналы изменений баз данных - протокол, в котором регис­трируются в хронологическом порядке исходные и обновленные состояния всех записей базы данных, модифицированных в процессе исполнения транзакций. Ведение журнала обеспечивается многими СУБД и применяется при процедурах восстановления.

В случае обновления на подписчике (immediate updating subscribers) тиражирование инициируется издателем. Как только издатель подтвер­ждает транзакцию, он сообщает дистрибьютеру о том, что данные изменены. Дистрибьютер забирает подтвержденную транзакцию и рассылает ее подписчикам. Если во время завершения транзакции связь между дистрибьютером и издателем была прервана, то транзак­ция записывается в очередь и будет передана дистрибьютеру, как толь­ко связь восстановится. Дальнейшее распространение данных выпол­няет дистрибьютер либо принудительно, либо по запросу. Транзак­ции проводятся только через издателя.

10.6. Обеспечение целостности и безопасности данных в РБД

10.6.1. Особенности обеспечения целостности в РБД

Существует ряд проблем обеспечения ограничений целостно­сти распределенной БД, помимо тех аспектов, которые присущи лю­бым БД:

1. возможность одновременного доступа нескольких пользовате­лей к одной и той же информации (особенно если эти обращения к БД - корректирующие);

2. физический разброс отдельных частей БД по разным компью­терам;

3. разнотипность источников информации.

Первая проблема имеет место в любых РБнД, вторая - если база данных является распределенной, третья - если система является ге­терогенной.

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

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

• запрещение корректировки информации, если ее корректирует другой пользователь (блокировка);

• корректировка разных копий информационных единиц и пос­ледующее устранение возникающих коллизий.

Если СУБД предоставляет возможность выбора способа обес­печения целостности при многопользовательских обращениях, то на результат этого выбора будут влиять многие факторы, в том числе:

• степень конкуренции при выполнении корректирующих обра­щений - насколько часто возникает ситуация одновременной коррек­тировки одной и той же информационной единицы;

• ограничения на время реакции системы,

• требования к актуальности и непротиворечивости данных в каж­дый момент времени;

• характеристика технических средств.

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

Как известно, существует два подхода к обеспечению целостнос­ти в распределенных информационных системах - строгая целост­ность (tight consistency) и нестрогая целостность (loose consistency). Первый вариант гарантирует целостность данных в любой момент времени, например, с помощью двухфазного протокола фиксаций (2РС). Обеспечение строгой целостности требует высокого качества коммуникаций, поскольку все узлы должны быть постоянно доступ­ны. Второй подход допускает наличие временной задержки между внесением изменений в публикуемую базу и их отражением на узлах подписчиков.

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

Характеристики

Список файлов книги