Здраво свима. Владислав Родин је у контакту. Тренутно предајем курсеве о архитектури софтвера и архитектури софтвера високог стреса на ОТУС-у. У ишчекивању почетка новог тока курса Одлучио сам да напишем кратак оригинални материјал који желим да поделим са вама.
Увод
Због чињенице да ХДД може да изврши само око 400-700 операција у секунди (што је неупоредиво са типичним рпс за систем високог оптерећења), класична диск база представља уско грло архитектуре. Због тога је потребно обратити посебну пажњу на шеме скалирања овог складишта.
Тренутно постоје 2 обрасца скалирања базе података: репликација и дељење. Схардинг вам омогућава да скалирате операцију писања и, као резултат, смањите број обртаја по писању по серверу у вашем кластеру. Репликација вам омогућава да урадите исту ствар, али са операцијама читања. Овом обрасцу је посвећен овај чланак.
Репликација
Ако погледате репликацију на веома високом нивоу, то је једноставна ствар: имали сте један сервер, на њему су били подаци, а онда овај сервер више није могао да се носи са оптерећењем читања ових података. Додајте још неколико сервера, синхронизујете податке на свим серверима и корисник може да чита са било ког сервера у вашем кластеру.
Упркос очигледној једноставности, постоји неколико опција за класификацију различитих имплементација ове шеме:
- По улогама у групи (мастер-мастер или мастер-славе)
- Према посланим објектима (засновано на редовима, на основу изјава или помешано)
- Према механизму синхронизације чворова
Данас ћемо се позабавити тачком 3.
Како долази до обавезивања трансакције?
Ова тема није директно повезана са репликацијом, о њој се може написати посебан чланак, али пошто је даље читање бескорисно без разумевања механизма урезивања трансакције, да вас подсетим на најосновније ствари. Обавеза трансакције се дешава у 3 фазе:
- Евидентирање трансакције у дневник базе података.
- Коришћење трансакције у машини базе података.
- Враћање потврде клијенту да је трансакција успешно примењена.
У различитим базама података овај алгоритам може имати нијансе: на пример, у ИнноДБ машини МиСКЛ базе података постоје 2 дневника: један за репликацију (бинарни дневник), а други за одржавање АЦИД-а (поништавање/редо дневник), док у ПостгреСКЛ-у постоји један дневник који обавља обе функције (напишите унапред лог = ВАЛ). Али оно што је горе представљено је управо општи концепт, који дозвољава да се такве нијансе не узимају у обзир.
Синхрона (синхронизирана) репликација
Хајде да додамо логику за реплицирање примљених промена у алгоритам урезивања трансакције:
- Евидентирање трансакције у дневник базе података.
- Коришћење трансакције у машини базе података.
- Слање података свим репликама.
- Примање потврде од свих реплика да је трансакција на њима завршена.
- Враћање потврде клијенту да је трансакција успешно примењена.
Са овим приступом добијамо низ недостатака:
- клијент чека да се промене примене на све реплике.
- како се број чворова у кластеру повећава, смањујемо вероватноћу да ће операција писања бити успешна.
Ако је све мање-више јасно са 1. тачком, онда су разлози за 2. тачку вредни објашњења. Ако током синхроне репликације не добијемо одговор од најмање једног чвора, враћамо трансакцију. Дакле, повећањем броја чворова у кластеру, повећавате вероватноћу да операција писања неће успети.
Можемо ли чекати потврду само од одређеног процента чворова, на пример, од 51% (кворум)? Да, можемо, али у класичној верзији потребна је потврда са свих чворова, јер на тај начин можемо обезбедити потпуну конзистентност података у кластеру, што је несумњива предност ове врсте репликације.
Асинхрона (асинхронизована) репликација
Хајде да изменимо претходни алгоритам. Податке ћемо послати репликама „некад касније“, а „некад касније“ промене ће бити примењене на реплике:
- Евидентирање трансакције у дневник базе података.
- Коришћење трансакције у машини базе података.
- Враћање потврде клијенту да је трансакција успешно примењена.
- Слање података у реплике и примена промена на њих.
Овакав приступ доводи до чињенице да кластер ради брзо, јер не чекамо клијента да подаци стигну до реплика, па чак и да буду предани.
Али услов дампинга података на реплике „некад касније” може довести до губитка трансакције, и до губитка трансакције коју је корисник потврдио, јер ако подаци нису имали времена да се реплицирају, потврда клијенту о успешности операције је послата, а чвор на који су стигле промене срушио ХДД, губимо трансакцију, што може довести до веома непријатних последица.
Полусинхронизована репликација
Коначно долазимо до полусинхроне репликације. Ова врста репликације није много позната или веома честа, али је од великог интереса јер може комбиновати предности и синхроне и асинхроне репликације.
Покушајмо да комбинујемо претходна 2 приступа. Нећемо дуго задржати клијента, али ћемо захтевати да се подаци реплицирају:
- Евидентирање трансакције у дневник базе података.
- Коришћење трансакције у машини базе података.
- Слање података у реплике.
- Пријем потврде од реплике да су промене примљене (оне ће бити примењене „некад касније“).
- Враћање потврде клијенту да је трансакција успешно примењена.
Имајте на уму да са овим алгоритмом до губитка трансакције долази само ако и чвор који прима промене и реплика чвор не успеју. Вероватноћа таквог квара се сматра малом и ови ризици се прихватају.
Али са овим приступом постоји могући ризик од фантомског читања. Замислимо следећи сценарио: у кораку 4 нисмо добили потврду ни од једне реплике. Морамо да вратимо ову трансакцију и не враћамо потврду клијенту. Пошто су подаци примењени у кораку 2, постоји временски размак између краја корака 2 и враћања трансакције, током којег паралелне трансакције могу да виде промене које не би требало да буду у бази података.
Полусинхронизована репликација без губитака
Ако мало размислите, можете само да обрнете кораке алгоритма и решите проблем фантомског читања у овом сценарију:
- Евидентирање трансакције у дневник базе података.
- Слање реплика података.
- Пријем потврде од реплике да су промене примљене (оне ће бити примењене „некад касније“).
- Коришћење трансакције у машини базе података.
- Враћање потврде клијенту да је трансакција успешно примењена.
Сада уносимо промене само ако су реплициране.
Излаз
Као и увек, не постоје идеална решења, постоји скуп решења, од којих свако има своје предности и мане и погодно је за решавање различитих класа проблема. Ово је апсолутно тачно за избор механизма за синхронизацију података у реплицираној бази података. Скуп предности које полусинхрона репликација има довољно је солидан и интересантан да се може сматрати вредним пажње, упркос ниској распрострањености.
То је све. Видимо се на !
Извор: ввв.хабр.цом