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

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

Защо ми е това?

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

Запознайте се с компромиса

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

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

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

Компромис 2: Съгласие

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

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

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

Компромис 3: Неуспехи

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

По едно връзка на транзакция?

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

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

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

По подразбиране PostgreSQL осигурява последователност. Това се контролира от параметъра на сървъра synchronous_commit. По подразбиране е в положение on, но има три други опции: local, remote_write или off.

При настройване на параметъра на off спират всички синхронни комити, дори в локалната система. Параметърът local определя синхронен режим за локалната система, но записите в реплики се извършват асинхронно. Remote_write идва още по-далеч: записите в реплики се извършват асинхронно, но се връщат, когато репликата приеме записа, но не го запише на диск.

Разглеждайки наличния диапазон от опции, ние избираме поведението и, имайки предвид, че on – това са синхронни записи, ще изберем local за асинхронни комити по мрежата, като оставим локалните комити синхронни.

Сега ще ви разкажем как да настроите това за миг, но си представете, че сме инсталирали synchronous_commit в local за сървъра. Зададохме си въпроса дали можем да променяме параметъра synchronous_commit в реално време, и се оказа, че не само че можем, но дори има два начина. Първият е да зададете сесията на вашето свързване по следния начин:

SET SESSION synchronous_commit TO ON;  
// Вашите записи идват тук

Всички последващи записи в сесията ще потвърдят операциите на запис за репликите, преди да върнат положителен резултат на свързания клиент. Ако, разбира се, не промените настройката synchronous_commit отново. Можете да пропуснете частта SESSION в командата, тъй като тя ще бъде по подразбиране.

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

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Вашите записи идват тук
COMMIT;  

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

Настройка на PostgreSQL

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

synchronous_commit = local  
synchronous_standby_names='*'

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

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

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

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

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

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

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