Straipsnio vertimas buvo parengtas specialiai kurso studentams "duomenų bazė". Norite vystytis šia kryptimi? Kviečiame į Atvirų durų diena, kuriame išsamiai kalbame apie programą, internetinio formato ypatybes, kompetencijas ir karjeros perspektyvas, kurios laukia absolventų po mokymų.

PostgreSQL ir ryšiams būdingi rašymo nuoseklumo nustatymai
Kompanijoje Compose dirbame su daugybe duomenų bazių, o tai suteikia galimybę geriau susipažinti su jų funkcionalumu ir trūkumais. Kai išmokstame pamilti naujų duomenų bazių ypatybes, kartais pradedame galvoti, kaip būtų puiku, jei panašių funkcijų būtų ir brandesniuose įrankiuose, su kuriais dirbame ilgą laiką. Viena iš naujų funkcijų, kurias norėjau pamatyti „PostgreSQL“, buvo konfigūruojamas rašymo nuoseklumas kiekvienam ryšiui visame klasteryje. Ir kaip paaiškėjo, mes jį jau turime, o šiandien norime su jumis pasidalinti informacija, kaip galite ją panaudoti.

Kodėl man to reikia?

Tai, kaip turėtų veikti klasteris, priklauso nuo jūsų programos. Paimkite, pavyzdžiui, sąskaitų apmokėjimo programą. Jums reikės XNUMX% nuoseklumo visame klasteryje, todėl turėsite įjungti sinchroninius įsipareigojimus, kad jūsų duomenų bazė lauktų, kol bus atlikti visi pakeitimai. Tačiau jei jūsų programa yra sparčiai augantis socialinis tinklas, greičiausiai pirmenybę teiksite greitam atsakymui, o ne XNUMX% nuoseklumui. Norėdami tai pasiekti, savo klasteryje galite naudoti asinchroninius įsipareigojimus.

Susipažinkite su kompromisu

Turite padaryti kompromisus tarp duomenų nuoseklumo ir našumo. PostgreSQL nutolsta nuo nuoseklumo, nes numatytoji konfigūracija yra nuspėjama ir be netikėtų staigmenų. Dabar pažvelkime į kompromisus.

1 kompromisas: našumas

Jei PostgreSQL klasteriui nereikia nuoseklumo, jis gali veikti asinchroniškai. Įrašoma klasterio lyderiui, o atnaujinimai bus išsiųsti į jo kopijas po kelių milisekundžių. Kai PostgreSQL klasteriui reikalingas nuoseklumas, jis turi veikti sinchroniškai. Rašymas bus atliktas klasterio vadovui, kuris išsiųs replikų atnaujinimą ir lauks patvirtinimo, kad kiekviena parašė, prieš išsiųsdama patvirtinimą klientui, kuris inicijavo rašymą, kad tai buvo sėkminga. Praktinis skirtumas tarp šių metodų yra tas, kad asinchroniniam metodui reikia dviejų tinklo apynių, o sinchroniniam metodui - keturių.

2 kompromisas: nuoseklumas

Rezultatas lyderio nesėkmės atveju taikant šiuos du metodus taip pat skirsis. Jei darbas atliekamas asinchroniškai, tada, įvykus tokiai klaidai, kopijos atliks ne visus įrašus. Kiek bus prarasta? Priklauso nuo pačios programos ir replikacijos efektyvumo. Sukūrimo replikacija neleis kopijai tapti lydere, jei informacijos kiekis joje yra 1 MB mažiau nei lyderyje, ty asinchroninio veikimo metu gali būti prarasta iki 1 MB įrašų.

Tai neįvyksta sinchroniniu režimu. Jei lyderiui nepavyksta, visos kopijos atnaujinamos, nes bet koks lyderio įrašas turi būti patvirtintas kopijose. Tai yra nuoseklumas.

Sinchroninis elgesys yra prasmingas atsiskaitymo programoje, kur nuoseklumas turi aiškų pranašumą nuoseklumo ir našumo kompromise. Tokiai programai svarbiausia yra galiojantys duomenys. Dabar pagalvokite apie socialinį tinklą, kuriame pagrindinė užduotis yra išlaikyti vartotojo dėmesį kuo greičiau atsakant į užklausas. Šiuo atveju prioritetas bus našumas su mažiau tinklo šuoliu ir mažiau laukimo iki įsipareigojimų. Tačiau reikia galvoti ne tik apie kompromisą tarp našumo ir nuoseklumo.

3 kompromisas: gedimai

Labai svarbu suprasti, kaip klasteris elgiasi nesėkmės metu. Apsvarstykite situaciją, kai viena ar daugiau kopijų nepavyksta. Kai įsipareigojimai apdorojami asinchroniškai, lyderis veiks toliau, tai yra, priims ir apdoros įrašus, nelaukdamas, kol bus trūkstamos kopijos. Kai kopijos grįžta į klasterį, jos pasiveja lyderį. Naudojant sinchroninį replikavimą, jei kopijos nereaguoja, lyderis neturės kito pasirinkimo ir toliau lauks patvirtinimo, kol kopija grįš į klasterį ir galės priimti bei atlikti įrašymą.

Vienas ryšys per operaciją?

Kiekvienai programai reikia skirtingo nuoseklumo ir našumo derinio. Nebent, žinoma, tai yra mūsų sąskaitų apmokėjimo programa, kurią įsivaizduojame kaip visiškai nuoseklią, arba mūsų beveik trumpalaikė socialinio tinklo programa. Visais kitais atvejais kai kurios operacijos turi būti sinchroninės, o kai kurios – asinchroninės. Galbūt nenorėsite, kad sistema lauktų, kol į pokalbį bus išsiųstas pranešimas, tačiau jei mokėjimas apdorojamas toje pačioje programoje, turėsite palaukti.

Visus šiuos sprendimus, žinoma, priima programos kūrėjas. Priimdami tinkamus sprendimus, kada naudoti kiekvieną metodą, galėsite išnaudoti visas grupės galimybes. Svarbu, kad kūrėjas galėtų perjungti juos SQL lygiu ryšiams ir operacijoms.

Kontrolės užtikrinimas praktiškai

Pagal numatytuosius nustatymus PostgreSQL užtikrina nuoseklumą. Tai valdoma serverio parametru synchronous_commit. Pagal numatytuosius nustatymus jis yra padėtyje on, bet yra trys kitos parinktys: local, remote_write arba off.

Nustatydami parametrą į off visi sinchroniniai įsipareigojimai sustabdomi net vietinėje sistemoje. Vietinis parametras nurodo vietinės sistemos sinchroninį režimą, tačiau įrašymas į kopijas vykdomas asinchroniškai. Remote_write eina dar toliau: įrašai į replikas atliekami asinchroniškai, bet grąžinami, kai replika priima rašymą, bet neįrašė jo į diską.

Atsižvelgdami į turimas galimybes, pasirenkame elgesį ir turėdami tai omenyje on – tai sinchroniniai įrašai, pasirinksime mes local asinchroniniams įsipareigojimams tinkle, o vietiniai įsipareigojimai paliekami sinchroniškai.

Dabar mes jums pasakysime, kaip tai nustatyti akimirksniu, bet įsivaizduokite, kad mes nustatėme synchronous_commit в local serveriui. Pasidomėjome, ar įmanoma pakeisti parametrą synchronous_commit skrydžio metu, ir paaiškėjo, kad tai ne tik įmanoma, bet yra net du būdai tai padaryti. Pirmiausia turite nustatyti ryšio seansą taip:

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

Visi vėlesni seanso įrašai patvirtins įrašus į replikas prieš grąžinant teigiamą rezultatą prijungtam klientui. Nebent, žinoma, pakeisite nustatymą synchronous_commit vėl. Galite praleisti dalį SESSION komandoje, nes ji bus numatytoji vertė.

Antrasis metodas yra geras, kai tiesiog norite įsitikinti, kad gaunate sinchroninį vienos operacijos replikaciją. Daugelyje NoSQL kartos duomenų bazių transakcijų sąvoka neegzistuoja, tačiau ji egzistuoja PostgreSQL. Tokiu atveju pradedate operaciją ir nustatote synchronous_commit в on prieš atliekant sandorio įrašą. COMMIT atliks operaciją naudodamas bet kurią parametro reikšmę synchronous_commit, kuris buvo nustatytas tuo metu, nors geriausia nustatyti kintamąjį iš anksto, kad kiti kūrėjai suprastų, jog rašymas nėra asinchroninis.

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

Visi operacijų įsipareigojimai dabar bus patvirtinti kaip įrašyti į replikas, kol duomenų bazė prijungtam klientui pateiks teigiamą atsakymą.

„PostgreSQL“ konfigūravimas

Prieš tai mes įsivaizdavome PostgreSQL sistemą su synchronous_commit, įdiegta local. Kad serverio pusėje tai būtų realu, turėsite nustatyti dvi serverio konfigūracijos parinktis. Dar vienas parametras synchronous_standby_names ateis savaime, kai synchronous_commit bus on. Jis nustato, kurios kopijos tinka sinchroniniam įpareigojimui, ir mes ją nustatysime *, o tai reikš, kad bus įtrauktos visos kopijos. Šios reikšmės paprastai sukonfigūruojamos konfigūracijos failą pridedant:

synchronous_commit = local  
synchronous_standby_names='*'

Nustatydami parametrą synchronous_commit į prasmę local, sukuriame sistemą, kurioje vietiniai diskai lieka sinchroniški, bet tinklo replikų įpareigojimai pagal numatytuosius nustatymus yra asinchroniniai. Nebent, žinoma, nuspręstume šiuos įsipareigojimus padaryti sinchroniškais, kaip parodyta aukščiau.

Jei sekėte raidą Gubernatoriaus projektas, galbūt pastebėjote kai kuriuos naujausius pakeitimus (1, 2), kuri leido Governor vartotojams išbandyti šiuos parametrus ir stebėti jų nuoseklumą.

Dar keli žodžiai...

Vos prieš savaitę būčiau jums sakęs, kad PostgreSQL taip tiksliai sureguliuoti neįmanoma. Tada Kurtas, Compose platformos komandos narys, tvirtino, kad tokia galimybė egzistuoja. Jis nuramino mano prieštaravimus ir rado PostgreSQL dokumentacijoje taip:

Šį nustatymą galima bet kada pakeisti. Bet kurios operacijos elgesį lemia įsipareigojimo metu galiojantis nustatymas. Todėl kai kurias operacijas galima ir naudinga atlikti sinchroniškai, o kitas – asinchroniškai. Pavyzdžiui, priversti vieną multistatement operaciją, kad būtų atlikti įsipareigojimai asinchroniškai, kai numatytoji parametro reikšmė yra priešinga, nustatyti SET LOCAL synchronous_commit TO OFF sandoryje.

Atlikę šį nedidelį konfigūracijos failo pakeitimą, suteikėme vartotojams galimybę kontroliuoti jų nuoseklumą ir našumą.

Šaltinis: www.habr.com