Има онлайн приложение за колежанска книжарница, където много студенти могат да купуват книги. Всеки път, когато ученик влезе, той показва списък с предложения въз основа на предишната им история на покупките. SQL Server, който съхранява клиентските данни, е в Сиатъл, но тези студенти влизат от цял свят. Следователно производителността може да пострада и тези, които са по-далеч в WAN, може да изпитат забавяне във времето за заявки.
Вместо учениците, които са по-далеч, да страдат от бавно време за зареждане на страници, репликацията може да се използва за копиране и поддържане на обекти на база данни в множество сайтове и синхронизиране по-късно, така че да се поддържа последователност. Всеки сайт съхранява частта от базата данни, която съдържа данните, които са най-подходящи за тях и най-често използвани. Сега всеки ученик може да закупи книги на уебсайта и данните ще бъдат синхронизирани по-късно.
Как работи репликацията на данни
Има няколко сървърни компонента и те поемат различни роли, за да реализират репликация. Ролята на издател е екземпляр на база данни, където се намира източникът на данните и съдържа обекти, които са проектирани като статии за репликация. Тези статии са групирани и публикувани в публикация, така че данните да се репликират като единица. Издателят може да има множество публикации.
Ролята на дистрибутор е екземпляр на база данни, който държи базите данни за разпространение. Всеки издател е съпоставен с една база данни за разпространение, която съхранява репликираните данни от издателя, които трябва да бъдат предадени на абоната. Дистрибуторът може да бъде настроен като локален дистрибутор, което означава, че един екземпляр на сървъра може да служи в ролите както на издател, така и на дистрибутор. Ако дистрибуторът е конфигуриран на отделни сървъри, той се нарича отдалечен дистрибутор.
Ролята на абонат е екземплярът(ите), който получава репликираните данни, като се абонира за публикациите. Абонатът не е ограничен и има право да получава данни от множество издатели, като обектите могат да бъдат актуализирани в зависимост от типа репликация. Ако е приложимо, издателят ще получи тези промени от абоната и ще публикува отново данните.
Като цяло, абонатът получава промени в данните по два начина:чрез push абонамент или абонамент за изтегляне. Разликата е в това кой сървърен компонент извършва актуализациите. С push, дистрибуторът избутва или директно актуализира базата данни на абонатите. С изтегляне абонатът проверява при дистрибутора, за да види дали е имало промени, и той сам ще извърши актуализацията.
Три типа репликация на данни
За реализиране на репликация се използват няколко агента за изпълнение на задачите, свързани с копиране на промените, проследяване на промените и разпространение на данните. Какви агенти са необходими зависи от вида на използваната репликация. Има три основни типа репликация.
1. Репликация на моментна снимка
Репликацията на моментна снимка е най-простият тип репликация на данни и се използва, ако данните не се променят толкова често или ако трябва да се репликират малки обеми данни. Например, ако има таблици, които не се актуализират много, тогава агентите за моментни снимки могат да се използват за копиране на цялата база данни веднъж или многократно според график. След това агентът по разпространение е отговорен за прехвърлянето на тези файлове на абоната.
Тази техника изисква малко поддръжка, тъй като това, което се разпространява, е моментна снимка на данните в определен момент от време. Също така, няма нужда да следите за промени, защото всеки път, когато абонатът получи актуализация, той презаписва цялото копие на данните.
За съжаление, копирането на цяла база данни може да допринесе за висока латентност или повече чакания, отколкото е желателно. Генерирането на моментни снимки изисква задържане на ключалки върху обекти. Не е удобно, ако данните се променят често и има вероятност да повлияят на производителността – например, ако издателят има много дейности по вмъкване, актуализиране и изтриване.
В допълнение към използването на агентите за моментни снимки за създаване на моментни снимки, транзакционните репликации също се възползват от агентите за четене на журнали, които се изпълняват при дистрибутора. Агентът за четене на журнали чете регистрационните файлове на транзакциите в базата данни на издателя и доставя само маркираните промени, вместо да чака за цяла база данни. Това осигурява гъвкавост, защото ви дава възможност да решите каква част от базата данни да публикувате (например колона). След това агентът за разпространение премества транзакциите към абонатите и там, където се изпълнява, ще се настанят съответно стратегиите за натискане и изтегляне на абонамент.
2. Репликация на транзакции
Стандартната транзакционна репликация предполага, че данните на абоната са само за четене. Въпреки това, има различни типове публикации, които позволяват да се правят модификации на абоната. Ако тези промени бъдат направени, те могат да бъдат препратени обратно на издателя за повторно публикуване. Агентът за четене на опашка се използва за двупосочна репликация на транзакции и ще чете промените от опашката и ще приложи тези в издателя.
Репликацията на транзакции е много полезна в среда от сървър към сървър, където могат да се правят промени в издателя и абоната в реално време – например данни в реално време относно това какви полети са налични в момента за дадена авиокомпания. В този случай няма смисъл да се използва репликация на моментна снимка, тъй като актуализациите обикновено се синхронизират веднъж на ден или по график.
3. Обединяване на репликация
Репликацията при сливане е като репликация на транзакции, но позволява актуализациите както на абоната, така и на издателя да бъдат обединени заедно. Много абонати могат да излязат офлайн, да правят актуализации на данните по различно време и след това да се върнат онлайн и да синхронизират тези промени по-късно.
Този тип репликация вероятно ще се използва в среди от сървър към клиент, като например мобилни клиенти. Подобно на репликацията на моментна снимка и транзакция, първоначалната моментна снимка се създава от агента за моментни снимки, но след това агентът за сливане ще проследява промените и ще разрешава конфликти с тригери. Ако няколко абонати актуализират едни и същи редове, те могат да причинят проблем. Следователно разрешаването на конфликта трябва да бъде отчетено.
