Диго С.М. Бази данни: дизайн и използване - файл n1.doc

Диго С.М. Бази данни: Въведение в базите данни. Методология на проектиране (документ)
Connolly T., Begg K., Strachan A. Бази данни: Проектиране, внедряване и поддръжка. Теория и практика (документ)
Степура Л.В., Шибут М.С. Бази данни на Access: Основи на базата данни (документ)
Бураков П.В., Петров В.Ю. Въведение в системите за бази данни (документ)
Презентация - Релационна база данни (Резюме)
ERWin 4.1.4 (документ)
Федоров Алексей, Елманова Наталия. Въведение в базите данни (документ)
Бабушкина Е.А., Бирюкова О.Ю., Верешчагина Л.С. База данни. Бележки от лекции (документ)
Карпова Т.С. Бази данни: модели, разработка, внедряване (документ)
Кирилов В.В. Основи на дизайна на релационни бази данни (документ)
Курсова работа - Разработване и анализ на информация за база данни Диагностичен център (Курсова работа)
Курсова работа - Бази данни в MS Access СУБД (Курсова работа)

10.5.3. Видове репликация

Има различни видове репликация. Те се различават по степента на транзакционна цялост и степента на автономност на възела (която по правило е обратно пропорционална една на друга). Изискванията към механизма за репликация зависят от задачите, които цялата изчислителна система решава като цяло.

Основните проблеми, които възникват в системите с репликация, са свързани с поддържането на постоянството на състоянието на всички копия. Има много схеми за актуализиране на копия в RDB.

Докато се правят промени в репликите, се прави разлика между синхронна и асинхронна репликация.

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

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

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

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

В случай насинхронна репликация, транзакцията се очаква да завърши само след като всички копия са били успешно модифицирани. Синхронната репликация използва механизма на двуфазно ангажиране (2PC) - Two-PhaseКомитиране: Главната система се свързва с подчинените копия на базите данни и едновременно с това прави промени в тях, като заключва съответните записи. Ако поне едно от тези копия не е налично, не се правят промени. Тъй като двуфазният механизъм за фиксиране налага високи изисквания към системата и намалява степента на автономност на възлите, той не се използва често в технологията за репликация.

За да се компенсират по някакъв начин недостатъците на синхронната репликация, се използварепликация във време, близко до реалното, което означава, че веднага след завършване на транзакцията на главния възел, промените автоматично се прехвърлят към репликираните копия. Но при този тип репликация, ако един от възлите е недостъпен, промените се съхраняват, докато връзката с получателя не бъде възстановена. Тази схема създава по-малко натоварване на мрежата и е подходяща за приложения, които не изискват стриктна синхронизация на копията на данни.

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

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

Протоколът ROWA е прост, но изисква всички копия на даден елемент да са налични, за да може транзакцията да завърши. Повреда на един от възлите ще доведе до дублирана транзакция, което намалява наличността на данни.

Бяха предложени няколко алтернативни алгоритъма за облекчаване на изискването на ROWA да се правят промени във всички копия едновременно.

Репликите в RDB за репликация могат да бъдатравностойниинеравностойни. През повечето време те са непоследователни. В този случай една от репликите се счита за основна. Дори ако има неравностойни реплики, има ситуации, в които е разрешено всяка реплика да бъде коригирана, но често само на главната реплика е разрешено да прави промени, докато други реплики са само за четене за потребителите. Тази схема на репликация се наричарепликация от основния сайт(първичен сайт). В този случай данните се копират асинхронно от главния към други реплики.

Тъй като такава схема на репликация налага повишени изисквания към безопасността на главната реплика и надеждността на работата на главния възел, понякога горният модел се допълва сгорещо архивиране (отказ) на главния възел. В този случай главният възел репликира промените както към подчинените възли, така и към резервния възел. Ако основният възел се повреди, тогава резервният възел става собственик на данните, който от този момент изпълнява всички свои функции.

Една техника, която може да се използва, ако се направят промени в локални реплики, ерепликация на сливане(репликация на сливане). Същността на метода е, че операциите се извършват на дистанционнокомпютър, който може дори да е напълно изключен от компютърната мрежа. Автономна СУБД записва всички операции с данни и техния ред. След това в определен момент автономният компютър се свързва с издателя (сървърът, на който се коригира базата данни, която подлежи на по-нататъшна репликация) и координира своите данни с него, като изпраща на издателя последователност от операции, извършени в отдалечената база данни. Когато възникнат конфликти, те се разрешават с помощта на различни алгоритми.

В някои системи функциите за формиране на "референтна" база и изпращане на реплики до крайни потребители (абонати) се разпределят между различни възли на системата. В този случай, след сливането, издателят изпраща промените до сървъра за разпространение за по-нататъшно разпространение до абонатите.

Репликацията на сливане осигурява максимална автономност на отдалечена база данни.

При използването на този метод могат да възникнат сблъсъци, които трябва да бъдат добре разбрани и предотвратени с различни средства, както технически, така и организационни.

Освен това има така нареченитепотокови модели на репликация(работен поток). В този модел собственикът на данните се променя динамично: данните могат да се актуализират на различни възли, но във всеки един момент само един от тях има такива права. Възлите последователно актуализират своите данни и възпроизвеждат промените в цялата система.

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

Друг критерий за класифициране на механизмите за репликация е атрибутът кой е инициаторът на актуализацията на репликите. Промените в репликите могат да бъдат инициирани от работни станции. Този процес на актуализиране се наричаактуализация при поискване. Актуализацията може да се извърши илиспоред определен графикилиръчно.

Незабавната репликация (наричана същоуправлявана от събития репликация) означава, че веднага щом транзакцията на основния възел завърши, промените се разпространяват автоматично към репликираните копия.

Методът, при който данните се четат от отдалечени възли от главните, се наричаизтеглянена промени, а методът за качване на данни към възли с копия се нарича натискане на промени.

В процеса нарепликация на транзакции(репликация на транзакции) от издателя към абонатите не се прехвърлят данни, а операции върху тях. Самата актуализация се извършва на работната станция. Прехвърлянето на транзакция може да се използва само когато съдържащата се база данни вече съдържа копие на основната база данни. При използване на тази схема е необходимо периодично да се извършва пълна синхронизация на данните, която се извършва по метода за репликиране на моментна снимка на данни. Транзакционната репликация се използва най-добре, когато размерът на базата данни е голям и върху тях се извършват малко операции.

В BnD като цяло и особено в разпределените, една от най-важните задачи е да се гарантира целостта на базите данни, включително възстановяването на бази данни следтяхното унищожаване. За тези цели се използватдневници на промените в базата данни- протокол, в който първоначалните и актуализираните състояния на всички записи в базата данни, модифицирани по време на изпълнение на транзакции, се записват в хронологичен ред. Регистрирането се предоставя от много СУБД и се използва в процедурите за възстановяване.

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