Prijevod članka pripremljen je posebno za studente kolegija "Baza podataka". Zainteresirani ste za razvoj u ovom smjeru? Pozivamo vas da Otvoreni dan, gdje detaljno govorimo o programu, značajkama online formata, kompetencijama i izgledima za karijeru koji čekaju diplomante nakon obuke.

PostgreSQL i postavke dosljednosti pisanja specifične za vezu
U Composeu imamo posla s mnogo baza podataka, što nam daje priliku da se pobliže upoznamo s njihovom funkcionalnošću i nedostacima. Dok učimo voljeti značajke novih baza podataka, ponekad počnemo razmišljati kako bi bilo lijepo kada bi slične značajke bile prisutne u zrelijim alatima s kojima već dugo radimo. Jedna od novih značajki koju sam želio vidjeti u PostgreSQL-u bila je podesiva dosljednost pisanja po vezi u cijelom klasteru. I kako se pokazalo, već ga imamo, a danas želimo s vama podijeliti informacije o tome kako ga možete koristiti.

Zašto mi to treba?

Kako bi se klaster trebao ponašati ovisi o vašoj aplikaciji. Uzmimo, na primjer, aplikaciju za plaćanje računa. Trebat će vam XNUMX% dosljednost u cijelom klasteru, tako da ćete morati omogućiti sinkrone obveze kako bi vaša baza podataka čekala da se izvrše sve promjene. Međutim, ako je vaša aplikacija brzorastuća društvena mreža, vjerojatno ćete više voljeti brzi odgovor u odnosu na XNUMX% dosljednost. Da biste to postigli, možete koristiti asinkrone obveze u vašem klasteru.

Nađite kompromis

Morate napraviti kompromis između dosljednosti podataka i izvedbe. PostgreSQL se udaljava od dosljednosti jer je zadana konfiguracija tada predvidljiva i bez neočekivanih iznenađenja. Sada pogledajmo kompromise.

Kompromis 1: Izvedba

Ako klaster PostgreSQL ne zahtijeva dosljednost, može raditi asinkrono. Zapisivanje se vrši u voditelju klastera, a ažuriranja će biti poslana njegovim replikama nekoliko milisekundi kasnije. Kada PostgreSQL klaster zahtijeva dosljednost, mora raditi sinkrono. Zapisivanje će se izvršiti voditelju klastera, koji će poslati ažuriranje replikama i čekati potvrdu da je svaka upisala prije slanja potvrde klijentu koji je pokrenuo pisanje da je bilo uspješno. Praktična razlika između ovih pristupa je u tome što asinkrona metoda zahtijeva dva mrežna skoka, dok sinkrona metoda zahtijeva četiri.

Kompromis 2: Dosljednost

Rezultat u slučaju neuspjeha voditelja u ova dva pristupa također će biti različit. Ako se posao izvodi asinkrono, tada ako se takva pogreška dogodi, replike neće predati sve zapise. Koliko će biti izgubljeno? Ovisi o samoj aplikaciji i učinkovitosti replikacije. Replikacija sastavljanja spriječit će repliku da postane vodeća ako je količina informacija u njoj 1 MB manja od one u vodećoj, odnosno do 1 MB zapisa potencijalno bi moglo biti izgubljeno tijekom asinkronog rada.

To se ne događa u sinkronom načinu rada. Ako vodeći ne uspije, sve replike se ažuriraju, budući da svako pisanje potvrđeno na vodeći mora biti potvrđeno na replikama. Ovo je dosljednost.

Sinkrono ponašanje ima smisla u aplikaciji za naplatu gdje dosljednost ima jasnu prednost u kompromisu između dosljednosti i izvedbe. Za takvu aplikaciju najvažniji su valjani podaci. Sada razmislite o društvenoj mreži u kojoj je glavna zadaća zadržati pozornost korisnika odgovarajućim što bržim zahtjevima. U ovom slučaju, izvedba s manje mrežnih skokova i manje čekanja na predaju bit će prioritet. Međutim, kompromis između izvedbe i dosljednosti nije jedini o kojem morate razmišljati.

Kompromis 3: Padovi

Vrlo je važno razumjeti kako se klaster ponaša tijekom kvara. Razmotrite situaciju u kojoj jedna ili više replika ne uspije. Kada se predaje obrađuju asinkrono, voditelj će nastaviti funkcionirati, odnosno prihvaćati i obrađivati ​​zapise, bez čekanja na replike koje nedostaju. Kada se replike vrate u klaster, sustižu vođu. Kod sinkrone replikacije, ako replike ne odgovore, voditelj neće imati izbora i nastavit će čekati potvrdu predaje dok se replika ne vrati u klaster i može prihvatiti i izvršiti pisanje.

Jedna veza po transakciji?

Svaka aplikacija treba drugačiju vrstu kombinacije dosljednosti i izvedbe. Osim, naravno, ako se ne radi o našoj aplikaciji za plaćanje računa, za koju zamišljamo da je potpuno dosljedna, ili našoj gotovo kratkotrajnoj aplikaciji za društveno umrežavanje. U svim ostalim slučajevima, postojat će trenuci kada neke operacije moraju biti sinkrone, a neke asinkrone. Možda ne želite da sustav čeka dok se poruka poslana u chat ne potvrdi, ali ako se plaćanje obradi u istoj aplikaciji, tada ćete morati pričekati.

Sve te odluke, naravno, donosi programer aplikacije. Donošenje ispravnih odluka o tome kada koristiti svaki pristup pomoći će vam da izvučete najviše iz svog klastera. Važno je da se programer može prebacivati ​​između njih na SQL razini za veze i za transakcije.

Osiguranje kontrole u praksi

Prema zadanim postavkama PostgreSQL osigurava dosljednost. Ovo je kontrolirano parametrom poslužitelja synchronous_commit. Standardno je na poziciji on, ali ima tri druge mogućnosti: local, remote_write ili off.

Prilikom postavljanja parametra na off sva sinkrona predaja se zaustavljaju, čak i na lokalnom sustavu. Lokalni parametar specificira sinkroni način za lokalni sustav, ali pisanje u replike izvodi se asinkrono. Remote_write ide još dalje: zapisi u replike vrše se asinkrono, ali se vraćaju kada je replika prihvatila pisanje, ali ga nije zapisala na disk.

Razmatrajući raspoloživi raspon opcija, odabiremo ponašanje i, imajući na umu da on – ovo su sinkrone snimke, mi ćemo birati local za asinkrona predavanja preko mreže, dok lokalna predavanja ostavljaju sinkronima.

Sada ćemo vam reći kako to postaviti za trenutak, ali zamislite da smo postavili synchronous_commit в local za poslužitelj. Pitali smo se je li moguće promijeniti parametar synchronous_commit u hodu, a pokazalo se da to nije samo moguće, već postoje čak dva načina za to. Prvo je postaviti sesiju vaše veze na sljedeći način:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

Sva naknadna pisanja u sesiji će potvrditi pisanja u replike prije vraćanja pozitivnog rezultata povezanom klijentu. Osim ako naravno ne promijenite postavku synchronous_commit opet. Možete izostaviti dio SESSION u naredbi jer će biti u zadanoj vrijednosti.

Druga metoda je dobra kada samo želite biti sigurni da ćete dobiti sinkronu replikaciju za jednu transakciju. U mnogim NoSQL generacijskim bazama podataka koncept transakcija ne postoji, ali postoji u PostgreSQL-u. U ovom slučaju započinjete transakciju, a zatim postavljate synchronous_commit в on prije izvršenja unosa za transakciju. COMMIT izvršit će transakciju koristeći bilo koju vrijednost parametra synchronous_commit, koji je postavljen u to vrijeme, iako je najbolje postaviti varijablu unaprijed kako bi bili sigurni da drugi programeri razumiju da pisanje nije asinkrono.

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

Sve obveze transakcije sada će biti potvrđene kao zapisane u replike prije nego što baza podataka vrati pozitivan odgovor povezanom klijentu.

Konfiguriranje PostgreSQL-a

Prije ovoga smo zamislili PostgreSQL sustav sa synchronous_commit, instaliran u local. Kako bi ovo bilo realno na strani poslužitelja, morat ćete postaviti dvije opcije konfiguracije poslužitelja. Još jedan parametar synchronous_standby_names doći će na svoje kada synchronous_commit bit će unutra on. Određuje koje replike ispunjavaju uvjete za sinkrono uvrštavanje, a mi ćemo ga postaviti na *, što će značiti da su uključene sve replike. Ove su vrijednosti obično konfigurirane u konfiguracijska datoteka dodavanjem:

synchronous_commit = local  
synchronous_standby_names='*'

Postavljanjem parametra synchronous_commit u vrijednosti local, stvaramo sustav u kojem lokalni diskovi ostaju sinkroni, ali su mrežne replike predaje asinkrone prema zadanim postavkama. Osim ako, naravno, ne odlučimo učiniti ove obveze sinkronima, kao što je prikazano gore.

Ako ste pratili razvoj Projekt guvernera, možda ste primijetili neke nedavne promjene (1, 2), što je korisnicima Guvernera omogućilo testiranje ovih parametara i praćenje njihove dosljednosti.

Još nekoliko riječi...

Prije samo tjedan dana, rekao bih vam da je nemoguće tako fino podesiti PostgreSQL. Tada je Kurt, član tima platforme Compose, inzistirao na tome da takva prilika postoji. Umirio je moje prigovore i pronašao u dokumentaciji PostgreSQL sljedeće:

Ova se postavka može promijeniti u bilo kojem trenutku. Ponašanje svake transakcije određeno je postavkom koja je na snazi ​​u vrijeme predaje. Stoga je moguće i korisno za neke transakcije izvršiti sinkrono, a za druge asinkrono. Na primjer, na silu multistatement transakcija za asinkrono izvršavanje kada je zadana vrijednost parametra suprotna, postavljena SET LOCAL synchronous_commit TO OFF u transakciji.

Ovom malom preinakom konfiguracijske datoteke dali smo korisnicima kontrolu nad njihovom dosljednošću i izvedbom.

Izvor: www.habr.com