Prevod članka je pripravljen posebej za študente tečaja «Podatkovne baze». Ali vas zanima razvoj na tem področju? Vabimo vas na Dan odprtih vrat, kjer podrobno predstavljamo program, značilnosti spletnega formata, kompetence in karierne možnosti, ki čakajo diplomante po izobraževanju.

PostgreSQL in nastavitve skladnosti zapisovanja za vsak posamezen povezavo.
Pri Compose se ukvarjamo z različnimi podatkovnimi bazami, prav to nam omogoča, da se podrobneje spoznamo z njihovo funkcionalnostjo in slabostmi. Ko se učimo imeti radi funkcionalne značilnosti novih podatkovnih baz, se včasih sprašujemo, kako bi bilo lepo, če bi bile takšne funkcije prisotne tudi v bolj zrelih orodjih, s katerimi že dolgo delamo. Ena od novih funkcij, ki bi jo želeli videti v PostgreSQL, je bila prilagodljiva doslednost zapisa po povezavi v celotnem klasterju. In kot se je izkazalo, jo že imamo, in danes želimo deliti z vami informacije o tem, kako jo lahko uporabite.

Zakaj mi to?

To, kako mora klaster delovati, je odvisno od vaše aplikacije. Vzemimo za primer aplikacijo za plačevanje računov. Potrebovali boste stoodstotno doslednost v klasterju, zato boste morali omogočiti sinhrone commit-e, da bo vaša podatkovna baza čakala, dokler ne bodo vnesene vse spremembe. Vendar, če je vaša aplikacija hitro razvijajoča se družbena omrežja, boste zagotovo raje izbrali hitro odzivnost pred stoodstotno doslednostjo. Da bi to dosegli, lahko uporabite asinhrone commit-e v vašem klasterju.

Spoznajte kompromis

Morali boste sprejeti kompromis med doslednostjo podatkov in zmogljivostjo. PostgreSQL koraka stran od doslednosti, saj privzeta konfiguracija v tem primeru postane predvidljiva brez nepričakovanih presenečenj. Zdaj pa spoznamo kompromisne rešitve.

Kompromis 1: Zmogljivost

Če PostgreSQL klaster ne zahteva skladnosti, lahko deluje asinhrono. Zapis se izvede na vodji klasterja, njegove replikam pa bodo poslane posodobitve po nekaj milisekundah. Ko klasteru PostgreSQL potrebna skladnost, mora delovati sinhrono. Zapis bo izveden na vodji klasterja, ki bo replikam poslal posodobitev in počakal na potrditev, da je vsak izvedel zapis, preden bo stranki, ki je iniciirala zapis, poslal potrditev, da je bila operacija uspešna. Praktična razlika med obema pristopoma je, da asinhrona metoda zahteva dva skoka po omrežju, sinhrona pa štiri.

Kompromis 2: Skladnost

Rezultat v primeru okvare vodje v obeh pristopih bo prav tako različen. Če se delo izvaja asinhrono, ob takšni napaki ne bodo vse zapise potrdile replike. Koliko jih bo izgubljenih? Odvisno je od same aplikacije in učinkovitosti replikacije. Replikacija Compose prepreči, da bi replika postala vodja, če je količina informacij v njej 1 MB manjša od vodje, kar pomeni, da lahko potencialno izgubi do 1 MB zapisov pri asinhronem delovanju.

V sinhronem načinu se to ne zgodi. Če vodja odpove, se vse replike posodobijo, saj mora biti vsak zapis, potrjen na vodji, potrjen tudi v replikah. To je skladnost.

Sinhrono vedenje ima smisla uporabiti v aplikaciji za plačila, kjer ima skladnost jasno prednost pri iskanju kompromisa med skladnostjo in zmogljivostjo. Najpomembnejše za to aplikacijo so veljavni podatki. Zdaj pomislite na družbeno omrežje, kjer je glavna naloga zadržati pozornost uporabnika in odgovoriti na njegove zahteve čim hitreje. V takem primeru bo zmogljivost s manj skoki po omrežju in manj čakanjem na potrditev prioriteta. Vendar kompromis med zmogljivostjo in skladnostjo ni edini, o katerem je treba razmišljati.

Kompromis 3: Okvare

Zelo je pomembno razumeti, kako se klaster obnaša med okvaro. Razmislimo o situaciji, ko ena ali več replik odpove. Ko se obdelujejo zaveze asinhrono, bo vodja še naprej deloval, torej sprejemal in obdeloval zapise, ne da bi čakal na manjkajoče replikacije. Ko se replike vrnejo v klaster, dohitevajo vodjo. Pri sinhroni replikaciji, če replike ne odgovarjajo, vodja nima izbire in bo še naprej čakal na potrditev zaveze, dokler se replika ne vrne v klaster in ne more sprejeti ter potrditi zapisa.

Eno povezavo na transakcijo?

Vsaka aplikacija potrebuje poseben tip ravnotežja med skladnostjo in zmogljivostjo. Seveda, razen našega plačilnega aplikacije, kjer si predstavljamo popolno skladnost, ali našega skoraj eterealnega družabnega omrežja. V vseh drugih primerih bodo trenutki, ko morajo biti nekateri postopki sinhroni, drugi pa asinhroni. Morda ne želite, da sistem čaka, dokler sporočilo poslane v klepet ne bo zaključen, vendar, če se v isti aplikaciji izvaja plačilo, bo treba počakati.

Vse te odločitve, seveda, sprejema razvijalec aplikacije. Prave odločitve o tem, kdaj uporabiti določen pristop, bodo pomagale iztisniti maksimum iz klasterja. Pomembno je, da se razvijalec lahko preklaplja med njimi na ravni SQL za povezave in za transakcije.

Zagotavljanje nadzora v praksi

Privzeto PostgreSQL zagotavlja skladnost. To se nadzira s strežniško nastavitvijo synchronous_commit. Privzeto je nastavljen na on, vendar ima tri druge možnosti: local, remote_write ili off.

Ko se parameter nastavi na off , se ustavijo vse sinhrone zaveze, tudi v lokalnem sistemu. Parameter v local določa sinhroni način za lokalni sistem, vendar so zapisi v replike izvedeni asinhrono. Remote_write gre še naprej: zapisi v replike se izvajajo asinhrono, vendar se vrnejo, ko je replika sprejela zapis, vendar ga ni zapisala na disk.

Ob razmisleku o obstoječem naboru možnosti izberemo vedenje in, ob spominu na to, da on – to so sinhroni zapisi, izberemo local za asinhrone zaveze po omrežju, pri čemer pustimo lokalne zaveze sinhrone.

Zdaj, povemo vam, kako to enostavno nastaviti, vendar si predstavite, da smo namestili synchronous_commit u local za strežnik. Spraševali smo se, ali je mogoče parameter synchronous_commit spremeniti v živo, in izkazalo se je, da ne le, da je to mogoče, ampak obstajata kar dva načina za to. Prvi način je, da nastavite sejo vašega povezovanja na naslednji način:

SET SESSION synchronous_commit TO ON;  
// Vaši zapisi gredo sem

Vsi nadaljnji zapisi v seji bodo potrdili operacije zapisovanja za replikacije, preden vrnejo pozitiven rezultat povezani stranki. Seveda, če ne spremenite nastavitve synchronous_commit spet. Del SESSION lahko izpustite v ukazu, saj bo imela privzeto vrednost.

Drugi način je dober, ko želite biti prepričani, da boste dobili sinhrono replikacijo za eno transakcijo. V mnogih bazah podatkov generacije 'NoSQL' koncept transakcij ne obstaja, vendar v PostgreSQL obstaja. V tem primeru začnete transakcijo in nato nastavite synchronous_commit u on pred izvedbo zapisa za transakcijo. COMMIT potrdi transakcijo, z uporabo katere koli vrednosti parametra synchronous_commit, ki je bila takrat nastavljena, čeprav je najbolje, da spremenljivko nastavite vnaprej, da se prepričate, da drugi razvijalci razumejo, da zapisi niso asinhroni.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Vaši zapisi gredo sem
COMMIT;  

Vsi commit-i transakcij bodo zdaj potrjeni, kot zapisani v replikah, preden baza podatkov vrne pozitiven odgovor povezani stranki.

Nastavitev PostgreSQL

Pred tem smo si predstavljali sistem PostgreSQL z synchronous_commit, nastavljenim na local. Da bo to resnično na strani strežnika, boste morali nastaviti dva konfiguracijska parametra strežnika. Še en parameter synchronous_standby_names bo stopil v veljavo, ko synchronous_commit bo v on. Določa, katere replikacije imajo pravico do sinhronih commit-ov, in nastavili bomo to na *, kar bo pomenilo vključitev vseh replik. Te vrednosti se običajno nastavljajo v konfiguracijskoj datoteci z dodajanjem:

synchronous_commit = local  
synchronous_standby_names='*'

Z nastavitvijo parametra synchronous_commit na vrednost local, ustvarjamo sistem, v katerem lokalni diski ostanejo sinhroni, vendar so commit-i mrežnih replik privzeto asinhroni. Seveda, če se ne odločimo, da naredimo te commit-e sinhrone, kot je prikazano zgoraj.

Če ste spremljali razvoj projekta Governor, ste lahko opazili nekatere nedavne spremembe (1, 2), ki so uporabnikom Governor omogočili preizkusiti te nastavitve in nadzorovati njihovo skladnost.

Še nekaj besed…

Še pred enim tednom bi vam rekel, da je skoraj nemogoče tako natančno nastaviti PostgreSQL. Takrat je Kurt, član ekipe platforme Compose, vztrajal, da to lahko storimo. Umiril je moje ugovore in našel v dokumentaciji PostgreSQL naslednje:

To možnost je mogoče spremeniti kadarkoli. Obnašanje katere koli transakcije je določeno z nastavitvijo, ki velja ob izvedbi ukaza commit. Zato je mogoče in koristno, da se za nekatere transakcije izvedbe commit zgodijo sinhrono, za druge pa asinhrono. Na primer, da omogočimo eno multistatement transakcijo, ki izvaja commit asinhrono, ko je privzeta vrednost parametra nasprotna, nastavite SET LOCAL synchronous_commit TO OFF v transakciji.

S to majhno modifikacijo v konfiguracijski datoteki smo omogočili uporabnikom, da nadzorujejo svojo skladnost in zmogljivost.

Izvor: habr.com