Highload младши блог

Andrei Aksenov (Sphinx)

Моят доклад е предназначен за тези хора, които знаят думата "репликация", дори знам, че в MySQL е, и може би веднъж му създаде, 15 минути, прекарани и забравени. Повече за това, че не знаят нищо.

Докладът ще бъде:

Всичко е там в интернет, направи разбор на синтаксиса, няма смисъл.

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

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

• синхронизиране степен промяна (синхронизация, асинхронен, semisync);
• запис на броя на сървъри (M / S, M / M);
• промени формат (резюме на базата (SBR), ред въз основа на (RBR), смесен);
• теоретично моделиране на промените на преносни (лицеви, издърпайте).

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

Т.е. Репликация - това е повече за четене.

За синхронизация.

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

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

Всичко това са обща терминология, абсолютно не свързан с MySQL. Във всеки разпределена система, тя е разположена така.

Asynchronous ангажират - без допълнителни гаранции като късмет.

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

За сървър за запис. Какви са различните видове репликация.

Master-роб класически, всички промени се изливат на един сървър, а след това копира на маса реплика.

Master-майстор вярно - когато промените се излива върху един куп майстори в същото време и по някакъв начин от единия към другия, а другият на третия и на всичките между тях, което води до редица удоволствия, и няколко автоматични въпроси. Ясно е, че когато имаш един-единствен "златен копие" и със себе си няколко забележки, които следва (в идеалния случай - в секунди), за да се повтаря "златния копие", всичко е относително просто от гледна точка на това как данните назад и напред, за да управлява и че да се направи за всеки един екземпляр. С майстор-капитанът започва интересно "главоболие", и, повтарям, не по-специално в случай на MySQL, но чисто теоретично. Как да бъде, ако двете nodah опит за едновременно задвижване на една и съща сделка, която променя същите данни, както и да ги променя, за простота пример, по различен начин. Ясно е, че и двете от тези две промени, не можем да се прилагат. По времето, когато започнем по един възел да промените нещо, на втория възел все още нищо. Конфликт. Една от сделките ще трябва да се връщам. индивид "Танц" Освен това, като се започне с синхронизацията на часовници и т.н.

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

Сега по-близо до базите данни, "магически" формат изявление основа, на базата на ред и т.н. За да променяте формата им.

Какво можете да направите? Можете да прехвърляте искания себе си, и вие може само трансфер променило линии. Искам да подчертая - ние все още не са се гмурна в джунглата на MySQL, той може да се справи с всяка база данни, в които има искания, генериращи голям (или не) стойността на промяната, т.е. подновяване на голямо количество данни. Това повдига въпроса - какво точно ще копира? Можете да направите заявките напред и назад между възли за шофиране, и че е възможно да карам само на променените данни. Интересно е, че така и това е много лошо! Можете също да опитате да се смесват.

Друг важен момент за това, има такива репликация. За модела на дистрибуция. Вероятно, някъде все още все още не е напълно изчезнал модел Push-базирани, когато този възел, което прави промени, а тя е длъжна да ги изпращате на всички други нови възли. От гледна точка на планирането и контрола state'ov това все още е объркване. Ето защо, таксита разтегателен основават. За да се вземе новини от определен възел - това е много по-лесно да се програмира от един възел да наблюдава хаотично групичката му реплики.

вписани Някои общи термини. Ние се обръщаме към начина, по който прави в MySQL.

MySQL, само по себе си, е един вид измама. Логична слой, наречен MySQL, която се занимава с всички общи и изолирана от случаите за съхранение на данни - оптимизатор мрежа, кеш и т.н. Конкретният физическия слой, който е отговорен за съхранение на данни се намира на етаж по-долу. Има няколко вградени, има поставят плъгини. Но дори и застроена MyISAM, InnoDB, и т.н. живея в физическия слой. Plug-in архитектура - това е готино, можете да вземете нов двигател, но веднага е налице известно не е оптимално. По принцип, за сделка запис напред log'i на (WAL), които са физически слой за съхранение все още пише, че би било добре да се използва, за да се възпроизведе, и ако системата не знае, че има известно физическо ниво, или достатъчно добре в двойка с физическия слой , тя може да бъде отделен дневник логично не пиша, и да използват една и съща Wal. Но MySQL е концептуално невъзможно, или ако промяната в PSE интерфейс, така че да стане възможно концептуално, ще има много работа.

Репликация се осъществява на равнището на MySQL. В това има добра - в допълнение към лог в дълбока вътрешна двигател съхранение, има повече или по-малко логично дневник, може би на ниво statement'ov, която се поддържа отделно от този двигател. Тази "екстра" сигурност и т.н. Плюс това, защото няма никакви ограничения вътре, можете да направите всякакъв вид творческа смяна на двигателя "в движение".

По отношение на провеждането на MySQL 4.1 е реализирана: майстор-роб, дръпнете основа, строго и стриктно асинхронен SBR. Ако можете да заседнат в древния 4.x ера, тогава може би сте чак толкова лошо. 5.x е вече почти 10 години - това е време за ъпгрейд.

Смешни следите версии, тъй като хората са поели всички видове гребла и кога да се направи нищо, беше невъзможно, завинтена към тази нова рейк гребла за живота не е толкова болезнено. Така че, в версия 5.1 затегна RBR, за да компенсира неизбежните проблеми с SBR, и стегна смесен режим. Във версия 5.6 затегна още приятни парчета: полу-синхронизация, забавено роб, GTID.

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

Какво прави на Учителя в момента, в който решите да включите репликация? На съветника случва доста допълнителни движения. Както обикновено, ние ще приемат заявки в мрежата, да ги направи разбор, преследване сделки, да ги коригира, и т.н. В допълнение, в логическото ниво започва да овладеят MySQL бинарен лог - файл, той не е текст, който заливат всичко се променя. Също така, капитанът е в състояние да изпрати тези трупи чрез мрежата. Всичко това е много прост и вид дела.

Какво е роб? Промени в роба-добре да не се изпращат, защото можете да получите в неразбираемото. В малко повече от роб работа. В допълнение, за да се запази едно допълнително дневник, и го изпраща при поискване, все още има нишка, която отива към отдалечен майстор, може би дори не един и вибрациите от двоичен log'i. Решение "да вървим към по-отдалечените майстори и да изтеглите различни трупи с тях", е нееднозначен. От една страна е добре, и се оказва, от друга моментно несъответствие. Само физически копирайте файловете на ПСС не може вече да се получи един дневник на сървъра, той позиции на местно ниво, ние ги дръпнете на стартовата решетка, сложи в отделен регистър, дори само една писти конец и се опитва да играе на тези местни трупи. Най-адски, по мое мнение, се крие във факта, че до версия 5.6 идентифицирането на определена сделка в дневника е станало на името на файла и позиция в съветника. Едно интересно решение.

Това е начинът, по записа, който е прост вложка минава без репликация:

Skonnektilos молба към сървъра, сложи на масата, и затвори.

С репликация получите няколко допълнителни стъпки:

Приложение писател просто отива на капитана, но в допълнение, тези данни идват в една или друга форма в двоичен дневника, а след това се люлее в мрежата да предават дневника, а след това от релето log'a постепенно repleyutsya (ако имахме късмет, и робът не закъсняват, repleyutsya вдясно) в таблицата на роба, в края на краищата това е на разположение в читателя.

Точно това, което става в двоичен дневник, в зависимост от настройките на SBR / RBR / смесена. Когато не спира да расте? Представляват себе си база данни. Летяхме по прост въпрос "поднови специален регистър" - потребители зададеният х = 123 WHERE ID = 456

Какво е писано в двоичен дневника? По принцип всички еднакви, наистина. Ние можем да запишете кратко разследване, или (както той се обновява един запис) може да пише на промяната по някакъв начин в определен формат.

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

Има един ефективен вариант - да напиша на заявката, защото заявката - точно 32 байта, а записите той може да се актуализира на произволен брой - 1000 100 000, 1 милион, колкото е необходимо. Неефективно да пише модифициран записи на дневника.

А какво би станало, ако ние поставяме регистър по прост въпрос "нека да изключите всички потребители, които не вход за дълго време" - потребители зададеният увреждания = 1 КЪДЕ LAST_LOGIN