Преводът на статията е изготвен специално за студентите от курса "База данни". Интересувате ли се от развитие в тази посока? Каним ви да Отворен ден, където говорим подробно за програмата, характеристиките на онлайн формата, компетенциите и перспективите за кариера, които очакват завършилите след обучение.

PostgreSQL и специфични за връзката настройки за последователност при запис
В Compose работим с много бази данни, което ни дава възможност да се запознаем по-добре с тяхната функционалност и недостатъци. Докато се научаваме да обичаме функциите на новите бази данни, понякога започваме да си мислим колко хубаво би било подобни функции да присъстват в по-зрелите инструменти, с които работим от дълго време. Една от новите функции, които исках да видя в PostgreSQL, беше конфигурируема последователност при запис на връзка в целия клъстер. И както се оказа, ние вече го имаме и днес искаме да споделим с вас информация как можете да го използвате.

Защо ми трябва?

Как трябва да се държи клъстерът зависи от вашето приложение. Вземете например приложение за плащане на сметки. Ще ви е необходима XNUMX% съгласуваност в клъстера, така че ще трябва да активирате синхронни ангажименти, така че вашата база данни да чака да бъдат направени всички промени. Въпреки това, ако вашето приложение е бързо развиваща се социална мрежа, тогава вероятно ще предпочетете бърз отговор пред XNUMX% последователност. За да постигнете това, можете да използвате асинхронни ангажименти във вашия клъстер.

Срещнете компромис

Трябва да правите компромиси между последователността на данните и производителността. PostgreSQL се отдалечава от последователността, тъй като тогава конфигурацията по подразбиране е предвидима и без неочаквани изненади. Сега нека да разгледаме компромисите.

Компромис 1: Производителност

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

Компромис 2: Последователност

Резултатът в случай на провал на лидера при тези два подхода също ще бъде различен. Ако работата се извършва асинхронно, тогава ако възникне такава грешка, не всички записи ще бъдат ангажирани от репликите. Колко ще бъдат загубени? Зависи от самото приложение и ефективността на репликацията. Съставянето на репликация ще попречи на реплика да стане водеща, ако количеството информация в нея е с 1 MB по-малко, отколкото във водещата, тоест до 1 MB записи могат потенциално да бъдат загубени по време на асинхронна работа.

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

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

Компромис 3: Сривове

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

Една връзка на транзакция?

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

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

Осигуряване на контрол на практика

По подразбиране PostgreSQL осигурява последователност. Това се контролира от параметъра на сървъра 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 в командата, защото ще бъде в стойността по подразбиране.

Вторият метод е добър, когато просто искате да сте сигурни, че получавате синхронна репликация за една транзакция. В много бази данни за генериране на NoSQL концепцията за транзакции не съществува, но съществува в PostgreSQL. В този случай започвате транзакция и след това задавате synchronous_commit в on преди извършване на записа за транзакцията. COMMIT ще извърши транзакцията, като използва всяка стойност на параметър synchronous_commit, което беше зададено по това време, въпреки че е най-добре да зададете променливата предварително, за да сте сигурни, че другите разработчици разбират, че записите не са асинхронни.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

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

Конфигуриране на PostgreSQL

Преди това си представихме PostgreSQL система с synchronous_commit, инсталиран в local. За да направите това реалистично от страна на сървъра, ще трябва да зададете две опции за конфигурация на сървъра. Още един параметър synchronous_standby_names ще дойде на себе си, когато synchronous_commit ще бъде в on. Той определя кои реплики отговарят на условията за синхронни ангажименти и ние ще го настроим на *, което ще означава, че всички реплики са включени. Тези стойности обикновено се конфигурират в конфигурационен файл добавяйки:

synchronous_commit = local  
synchronous_standby_names='*'

Чрез задаване на параметъра synchronous_commit в смисъл local, създаваме система, в която локалните дискове остават синхронни, но ангажиментите на мрежови реплики са асинхронни по подразбиране. Освен ако, разбира се, решим да направим тези ангажименти синхронни, както е показано по-горе.

Ако сте следили развитието Губернаторски проект, може би сте забелязали някои скорошни промени (1, 2), което позволи на потребителите на Governor да тестват тези параметри и да наблюдават тяхната последователност.

Още няколко думи...

Само преди седмица щях да ви кажа, че е невъзможно да настроите PostgreSQL толкова фино. Тогава Кърт, член на екипа на платформата Compose, настоя, че такава възможност съществува. Той успокои възраженията ми и намери в документацията на PostgreSQL следното:

Тази настройка може да бъде променена по всяко време. Поведението за всяка транзакция се определя от настройката, която е в сила в момента на извършване. Следователно е възможно и полезно за някои транзакции да се ангажират синхронно, а за други асинхронно. Например да принуди един multistatement транзакция за извършване на ангажименти асинхронно, когато стойността по подразбиране на параметъра е противоположна, зададена SET LOCAL synchronous_commit TO OFF в сделка.

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

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