Пресъздаване на бази данни - Член Блог Майкъл flonova

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

Издател-дистрибутор-абонат

Най-често се свързва с репликация на бази данни и ние вече ще говорим за базите данни за примера на MS SQL Server. И не само с класическите бази данни, но такава специализирана като Active Directory. Но този свят не е отменено, репликация може успешно да се използва за обикновени файлове, най-важното е правилният подход.

Репликация в MS SQL Server основава на три понятия - издателя. дистрибутор и абонат. За да се разбере какво означава това, е достатъчно да се обърнем към реалния ни живот, където издателят предоставя информация на дистрибутора, който го изпраща на абонатите. По същия начин, по компютърни живот. Но първо първите неща.

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

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

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

филтри базар

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

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

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

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

• данни се различават значително, но рядко;
• се изисква Абонат данни за само за четене;
• Тя може да бъде голямо закъснение, тъй като данните са обикновено само актуализира периодично,
• абонатът се изисква самостоятелност.

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

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

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

Репликация MS SQL Server

Много добре направено, за да се възпроизведе в MS SQL Server. Създаване просто като една стотинка, защото това е лесно да се направи с помощта на двама господари, но има капани, които съветникът не може да каже, както и наръчници просто мълчат. Така че нека накратко разясни процеса на конфигурация репликация и ще се фокусира върху подводни камъни, от които всички са мълчи като риба.

Първо трябва да се създаде издател и разпространител. За да направите това на сървър, изберете Tools | репликация | Създаване и управление на публикация. Аз бих препоръчал да се използва по-мощна машина за издателя. Първото нещо, което ние искаме съветника - изберете базата данни. Изберете, щракнете върху Създаване на публикация. и следващата фаза на сървъра ще ви подкани да създадете дистрибутор. По подразбиране дистрибутор поканена да направи една и съща машина.

Магьосникът изисква създаването на разпределителя на репликация

Конфигуриране на MS SQL Server Agent сметка

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

Изборът на вида на репликация

След като създадете издателя и абоната, трябва да създадете настройката е завършена. По време на създаването на абонат можете да регулирате плана за изпълнение на определени дни или интервали от време, през който трябва да се възпроизведе.

Златният ключ

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

Да приемем, че двата компютъра са Създадени са две различни записи с едни и същи идентификатори, сървърът какво да правя? Кой да избера записите? Идеята е, че в резултат на масата трябва да получите два записа, но не може да промени ID, особено ако масата е свързана и два записа със същия ключ не е възможно.

Проблемът е решен съвсем просто, трябва само да изпълните следните стъпки:

• 1. Създаване на копие на базата данни на издател на абонат компютъра.
• 2. Отворете таблицата прозорец за редактиране, или с помощта на SQL заявка, че издателят е да се определи първоначалната стойност на ключа 1, както и за абоната 1 милион.

Всичко е просто и красиво. Сега, когато запис се добавя към издателя на новия запис ще бъдат номерирани от 1, 2, 3, 4 и на Абоната 1000001, 1000002, 1000003. По този начин, записът няма скоро да се пресичат и конфликти никога не може да се случи, особено ако не се добавят записи в таблицата твърде интензивен. Ако се добавят бързо записите, а след това да се откаже и да използвате автоматичното нарастване поле GUID като ключов.

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

Ръчно стартиране репликация

Тиражиране на Active Directory (AD)

Active Directory, която се използва активно от Windows сървъри - тя е и база данни. Тя може да се разпространява, когато работата е свързана с няколко сървъра, и в същото време, потребителят трябва да бъде в състояние да влезете в някой от тях с една и съща парола. Как да го направя? Регистрирайте се на всеки сървър индивидуално? Глупаво и безсмислено. И тогава идва на помощ на репликация. Просто се запишете на един сървър и да предпише необходимите разрешения и ще бъде повторен при необходимост цялата информация.

АД репликация се извършва автоматично, и обикновено не изисква специални интервенции, но изисква по-добро разбиране на основната идея. Ако Active Directory ще бъде толкова лесно, нямаше да се счита тази технология отделно. Първо трябва да се разбере, че за се използва протокол за удостоверяване Kerberos и отговорността за тяхната достоверност отвежда на домейн контролер. Когато влезеш в сървъра, потребителското име и паролата се изпраща на сървъра, който проверява данните и ако е успешно произвежда бял билет. Не, разбира се, не бял билет, но въз основа на него потребителят получава определени права. Ако има желание и не е знание, Съветвам ви да се запознаете с Active Directory и Kerberos и нашата задача - репликация.

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

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

Конфликтите в Active Directory

Тъй репликация се забави, сървърът репликира пакети за актуализация. Всички промени в Active Directory и се натрупват в един момент да бъдат изпратени на всички домейн контролери. Това е добре, но поради забавянето и възможните проблеми. Да предположим, че в определен период от време, като в същото време е налице промяна в двете домейн контролери. Чия промени ще бъде повторен? Нека се опитаме да разберем.

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

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

В най-краен случай - когато версиите са същите, а дори и по време на промяна е идентичен. Разбира се, вероятността за това е твърде ниска, но това е, следователно, Active Directory, разработчиците в този случай, предпочитат да изберат промяната, която дойде със сървъра с голям световен GUID. Разбира се, това е глупав избор и може да бъде далеч от точен, но това някак си решава конфликта.

Всеки контролер получаване на промените, опитвайки vtulit други техни контролери в мрежата ви. Тук също има проблем - представете си, че имаме три от домейн контролера. Редактиране на обекта на земята, и той, разбира се, трябва да уведоми другата за промените. Те взеха тези промени, но в този момент втори контролер се опитва да се тъпча същата промяна връщат при нас или на трета домейн, който вече взе промяната. Какво да правим в този случай? Това е много проста - ние също имаме промяна версия и може да се намери, че е необходимо да се вземе под внимание, или вече е повторен.

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

Репликация АД чрез 56k

Копиране на данни на всеки 15 минути, удобни и приятни, но само ако всички домейн контролери са свързани помежду си високоскоростна връзка. Какво става, ако двама ръководители са в друга област или страна, където те могат да бъдат свързани към мрежата само телефонна линия? В този случай, трафик на репликация може да отнеме твърде много ресурси, и трафик не е достатъчно, за други задачи.

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

Възможностите, предлагани като потенциални възможности за съхранение на трафика, TechNet от MS:

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

Харесва ми първите два варианта, особено ако сайтовете са в една и съща часова зона. Но ако човек се намира в Москва, а другият в района на Чукотка, не че сме на обяд не може да стигне до там, когато в Москва в деня в Петропавловск полунощ.

Повече за репликация Active Directory (AD)

Ако искате да научите повече за репликация Acive Directory, и няма проблеми с английски, аз препоръчвам да изтеглите следния документ: www.certmag.com/bookshelf/C0617953.pdf. Това е 92 страници полезна и khaljavnogo измислица. Ако това не е достатъчно, а след това се движат по TechNet от Microsoft. Има информация се представя не като удобен и последователно, но много добри съвети.

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

Зад кулисите на тази статия е много интересна тема - Exchange Server репликация. Тя е много подобна на Active Directory и SQL Server, но има и някои интересни нюанси.

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