Защо може да е необходима полусинхронна репликация?

Здравейте на всички. Аз съм Владислав Родин. В момента преподавам курсове за архитектура на софтуер и архитектура на софтуер с високо натоварване на портала OTUS. В навечерието на новия поток на курса „Архитектурна на високи натоварвания“ реших да напиша кратък авторски материал, който искам да споделя с вас.

Въведение

Поради факта, че на HDD могат да се извършват само около 400-700 операции в секунда (което е несравнимо с типичните rps, които се налагат на високо натоварена система), класическата дискова база данни представлява тясно място в архитектурата. Затова е необходимо да се обърне специално внимание на моделите за мащабиране на това хранилище.

В момента съществуват 2 модела за мащабиране на базата: репликация и шардировка. Шардировката позволява да се мащабира операцията по запис и следователно да се намалят rps на записа на един сървър от вашия клъстер. Репликацията позволява да се прави същото, но с операциите по четене. Именно на този модел е посветена статията.

Репликация

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

Въпреки видимата простота, съществуват няколко варианта за класификация на различните реализации на тази схема:

• По роли в клъстера (master-master или master-slave)
• По предавани обекти (row-based, statement-based или mixed)
• По механизма за синхронизация на възлите

Днес ще разгледаме именно третия пункт.

Как се извършва комит на транзакция

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

1. Запис на транзакцията в журнала на базата данни.
2. Прилагане на транзакцията в движението на базата данни.
3. Връщане на потвърждение на клиента за успешно прилагане на транзакцията.

В различни бази в този алгоритъм могат да възникнат нюанси: например, в движка InnoDB на MySQL има 2 дневника: един за репликация (binary log), а другият за поддържане на ACID (undo/red log), докато в PostgreSQL има един дневник, който изпълнява и двете функции (write ahead log = WAL). Но тук е представена общата концепция, която позволява да не се вземат предвид тези нюанси.

Синхронна (sync) репликация

Нека добавим в алгоритъма на комита на транзакцията логика за репликиране на получените промени:

1. Запис на транзакцията в журнала на базата данни.
2. Прилагане на транзакцията в движението на базата данни.
3. Изпращане на данни на всички реплики.
4. Получаване на потвърждение от всички реплики за извършване на транзакцията.
5. Връщане на потвърждение на клиента за успешно прилагане на транзакцията.

С този подход получаваме редица недостатъци:

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

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

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

Асинхронна (async) репликация

Нека изменим предишния алгоритъм. Данните на репликите ще изпращаме "по-късно" и "по-късно" промените ще бъдат приложени на репликите:

1. Запис на транзакцията в журнала на базата данни.
2. Прилагане на транзакцията в движението на базата данни.
3. Връщане на потвърждение на клиента за успешно прилагане на транзакцията.
4. Изпращане на данни на реплики и прилагане на промените от тях.

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

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

Полусинхронна (semisync) репликация

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

Ще опитаме да обединим двата предишни подхода. Няма да задържаме клиента дълго, но ще изискваме репликация на данните:

1. Запис на транзакцията в журнала на базата данни.
2. Прилагане на транзакцията в движението на базата данни.
3. Изпращане на данни до репликите.
4. Получаване на потвърждение от репликата за получаване на промените (те ще бъдат приложени „някога по-късно“).
5. Връщане на потвърждение на клиента за успешно прилагане на транзакцията.

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

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

Lose-less semisync репликация

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

1. Запис на транзакцията в журнала на базата данни.
2. Изпращане на данни до репликата.
3. Получаване на потвърждение от репликата за получаване на промените (те ще бъдат приложени „някога по-късно“).
4. Прилагане на транзакцията в движението на базата данни.
5. Връщане на потвърждение на клиента за успешно прилагане на транзакцията.

Сега ние комитираме промените само ако те са репликирани.

Извод

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

С това приключвам. До нови срещи на курса!

Източник: habr.com