Превод чланка је припремљен посебно за студенте курса . Заинтересовани сте за развој у овом правцу? Позивамо вас да , где детаљно говоримо о програму, карактеристикама онлајн формата, компетенцијама и изгледима за каријеру који чекају дипломце након обуке.
ПостгреСКЛ и подешавања конзистентности писања специфична за везу
У Цомпосе-у се бавимо многим базама података, што нам даје прилику да се боље упознамо са њиховом функционалношћу и недостацима. Док учимо да волимо карактеристике нових база података, понекад почињемо да размишљамо како би било лепо када би сличне карактеристике биле присутне у зрелијим алатима са којима већ дуго радимо. Једна од нових карактеристика коју сам желео да видим у ПостгреСКЛ-у била је конфигурабилна конзистентност писања по конекцији у целом кластеру. И како се испоставило, ми га већ имамо, а данас желимо да поделимо са вама информације о томе како га можете користити.
Зашто ми то треба?
Како кластер треба да се понаша зависи од ваше апликације. Узмите, на пример, апликацију за плаћање рачуна. Биће вам потребна 100% доследност у целом кластеру, тако да ћете морати да омогућите синхрона урезивања тако да ваша база података чека да се изврше све промене. Међутим, ако је ваша апликација друштвена мрежа која се брзо развија, вероватно ћете више волети брз одговор у односу на 100% доследности. Да бисте то постигли, можете користити асинхрона урезивања у свом кластеру.
Упознајте компромис
Морате направити компромисе између конзистентности података и перформанси. ПостгреСКЛ се удаљава од доследности јер је подразумевана конфигурација тада предвидљива и без неочекиваних изненађења. Погледајмо сада компромисе.
Компромис 1: Перформансе
Ако ПостгреСКЛ кластер не захтева доследност, може да ради асинхроно. Записивање се врши лидеру кластера, а ажурирања ће бити послата његовим репликама неколико милисекунди касније. Када ПостгреСКЛ кластер захтева доследност, мора да ради синхроно. Писање ће бити обављено лидеру кластера, који ће послати ажурирање репликама и сачекати потврду да је свака написала пре него што пошаље потврду клијенту који је покренуо упис да је успешно. Практична разлика између ових приступа је у томе што асинхрони метод захтева два мрежна скока, док синхрони метод захтева четири.
Компромис 2: Конзистентност
Резултат у случају неуспеха лидера у ова два приступа такође ће бити другачији. Ако се посао обавља асинхроно, онда ако дође до такве грешке, реплике неће урезати све записе. Колико ће бити изгубљено? Зависи од саме апликације и ефикасности репликације. Репликација састављања ће спречити да реплика постане водећа ако је количина информација у њој 1 МБ мања него у вођи, то јест, до 1 МБ записа може бити изгубљено током асинхроног рада.
Ово се не дешава у синхроном режиму. Ако лидер не успе, све реплике се ажурирају, пошто свако уписивање потврђено на лидеру мора бити потврђено на репликама. Ово је доследност.
Синхроно понашање има смисла у апликацији за наплату где доследност има јасну предност у компромису између доследности и перформанси. Најважнија ствар за такву апликацију су валидни подаци. Сада размислите о друштвеној мрежи у којој је главни задатак да задржи пажњу корисника тако што ће одговорити на захтеве што је брже могуће. У овом случају, перформансе са мање мрежних скокова и мање чекања на урезивање биће приоритет. Међутим, компромис између перформанси и доследности није једини о коме морате размишљати.
Компромис 3: Падови
Веома је важно разумети како се кластер понаша током квара. Размотрите ситуацију у којој једна или више реплика не успе. Када се урезивања обрађују асинхроно, вођа ће наставити да функционише, односно прихвата и обрађује записе, без чекања на недостајуће реплике. Када се реплике врате у кластер, сустижу вођу. Код синхроне репликације, ако реплике не реагују, тада вођа неће имати избора и наставиће да чека потврду урезивања док се реплика не врати у кластер и може да прихвати и урезује писање.
Једна веза по трансакцији?
Свакој апликацији је потребна другачија комбинација доследности и перформанси. Осим ако се, наравно, не ради о нашој апликацији за плаћање рачуна, за коју замишљамо да је потпуно конзистентна, или о нашој скоро ефемерној апликацији за друштвено умрежавање. У свим другим случајевима, биће тренутака када неке операције морају бити синхроне, а неке асинхроне. Можда не желите да систем чека док се порука послата у ћаскање не изврши, али ако се уплата обрађује у истој апликацији, онда ћете морати да сачекате.
Све ове одлуке, наравно, доноси програмер апликације. Доношење исправних одлука о томе када користити сваки приступ ће вам помоћи да извучете максимум из свог кластера. Важно је да програмер може да прелази између њих на СКЛ нивоу за везе и за трансакције.
Обезбеђивање контроле у пракси
Подразумевано, ПостгреСКЛ обезбеђује доследност. Ово се контролише параметром сервера synchronous_commit. Подразумевано је на позицији on, али има три друге опције: local, remote_write или off.
Приликом подешавања параметра на off сва синхрона урезивања су заустављена, чак и на локалном систему. Локални параметар специфицира синхрони режим за локални систем, али се уписи у реплике обављају асинхроно. Remote_write иде још даље: уписи у реплике се врше асинхроно, али се враћају када реплика прихвати упис, али га није записала на диск.
Узимајући у обзир расположиви распон опција, бирамо понашање и, имајући то у виду on – ово су синхрони снимци, бираћемо local за асинхроне урезивања преко мреже, док локалне урезивања остављају синхроним.
Сада ћемо вам рећи како да ово подесите за тренутак, али замислите да смо ми поставили synchronous_commit в local за сервер. Питали смо се да ли је могуће променити параметар synchronous_commit у ходу, и испоставило се да је то не само могуће, већ постоје чак два начина да се то уради. Први је да подесите сесију ваше везе на следећи начин:
SET SESSION synchronous_commit TO ON;
// Your writes go hereСва наредна уписивања у сесији ће потврдити записе у реплике пре него што врате позитиван резултат повезаном клијенту. Осим ако, наравно, не промените поставку synchronous_commit опет. Можете изоставити део SESSION у команди јер ће бити у подразумеваној вредности.
Други метод је добар када само желите да будете сигурни да добијате синхрону репликацију за једну трансакцију. У многим базама података генерисања НоСКЛ концепт трансакција не постоји, али постоји у ПостгреСКЛ. У овом случају започињете трансакцију, а затим подешавате synchronous_commit в on пре извршења уноса за трансакцију. COMMIT ће извршити трансакцију користећи било коју вредност параметра synchronous_commit, који је постављен у то време, иако је најбоље унапред поставити променљиву како би се уверили да други програмери разумеју да уписи нису асинхрони.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT; Сва урезивања трансакција ће сада бити потврђена као написана у реплике пре него што база података врати позитиван одговор повезаном клијенту.
Подешавање ПостгреСКЛ-а
Пре овога, замислили смо ПостгреСКЛ систем са synchronous_commit, инсталиран у local. Да бисте ово учинили реалистичним на страни сервера, мораћете да подесите две опције конфигурације сервера. Још један параметар synchronous_standby_names доћи ће на своје када synchronous_commit биће у on. Он одређује које реплике испуњавају услове за синхрона урезивања, а ми ћемо га поставити на *, што ће значити да су све реплике укључене. Ове вредности се обично конфигуришу у додавањем:
synchronous_commit = local
synchronous_standby_names='*'Постављањем параметра synchronous_commit у смисао local, креирамо систем у коме локални дискови остају синхрони, али урезивања мрежних реплика су подразумевано асинхрона. Осим ако, наравно, не одлучимо да ове урезивања учинимо синхроним, као што је горе приказано.
Ако сте пратили развој , можда сте приметили неке недавне промене (, ), што је омогућило корисницима Гувернера да тестирају ове параметре и прате њихову конзистентност.
Још пар речи...
Пре само недељу дана, рекао бих вам да је немогуће тако фино подесити ПостгреСКЛ. Тада је Курт, члан тима платформе Цомпосе, инсистирао да таква прилика постоји. Умирио је моје примедбе и пронашао у документацији ПостгреСКЛ-а :
Ово подешавање се може променити у било ком тренутку. Понашање за било коју трансакцију је одређено поставком на снази у време урезивања. Стога је могуће и корисно да се неке трансакције обаве синхроно, а друге асинхроно. На пример, да се натера multistatement трансакција да изврши асинхроно урезивање када је подразумевана вредност параметра супротна, подешено SET LOCAL synchronous_commit TO OFF у трансакцији.
Са овом малом модификацијом конфигурационог фајла, дали смо корисницима контролу над њиховом доследношћу и перформансама.
Извор: ввв.хабр.цом