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

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

Въведение

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

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

Репликация

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

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

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

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

Как преминава комит на транзакцията

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lose-less полусинхронна репликация

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

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

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

Извод

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

Това е всичко. До нови срещи на курса!

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