Artikuluaren itzulpena ikastaroko ikasleentzat bereziki prestatu zen "Datu-basea". Norabide honetan garatzea interesatzen zaizu? gonbidatzen zaitugu Ate irekien eguna, non zehatz-mehatz hitz egiten dugu programari, lineako formatuaren ezaugarriei, konpetentziei eta tituludunei prestakuntzaren ondoren itxaroten dituzten lan-aukerei buruz.

PostgreSQL eta konexio espezifikoak idazteko koherentzia ezarpenak
Compose-n datu-base asko jorratzen ditugu, eta horrek aukera ematen digu haien funtzionaltasuna eta gabeziak ezagutzeko. Datu-base berrien ezaugarriak maitatzen ikasten dugun heinean, batzuetan pentsatzen hasten gara zeinen polita izango litzatekeen antzeko ezaugarriak egongo balira aspaldidanik lan egiten ari garen tresna helduagoetan. PostgreSQL-n ikusi nahi nuen ezaugarri berrietako bat kluster osoan konexio bakoitzeko idazketa-koherentzia konfiguragarria zen. Eta ondorioz, dagoeneko badugu, eta gaur zurekin nola erabili dezakezun informazioa partekatu nahi dugu.

Zergatik behar dut?

Klusterrak nola jokatu behar duen zure aplikazioaren araberakoa da. Hartu, adibidez, fakturak ordaintzeko aplikazio bat. Kluster osoan % XNUMXeko koherentzia beharko duzu, beraz, konpromiso sinkronikoak gaitu beharko dituzu, zure datu-baseak aldaketa guztiak egin arte itxaron dezan. Hala ere, zure aplikazioa hazten ari den sare soziala bada, ziurrenik erantzun azkarra nahiago izango duzu % XNUMXeko koherentzia baino gehiago. Hori lortzeko, konpromiso asinkronoak erabil ditzakezu zure klusterrean.

Konpromisoa bete

Datuen koherentziaren eta errendimenduaren arteko trukeak egin behar dituzu. PostgreSQL koherentziatik aldendu egiten da, konfigurazio lehenetsia gero aurreikusgarria delako eta ustekabeko ezustekorik gabe. Orain ikus ditzagun konpromisoak.

1. trukea: errendimendua

PostgreSQL clusterrak koherentziarik behar ez badu, modu asinkronoan exekutatu daiteke. Idazketa klusterraren liderrari egiten zaio eta eguneraketak bere errepliketara bidaliko dira milisegundo batzuk geroago. PostgreSQL kluster batek koherentzia behar duenean, sinkronoki exekutatu behar du. Idazketa klusterraren liderrari egingo zaio, honek erreplikei eguneraketa bat bidaliko die eta bakoitzak idatzi duen baieztapenaren zain egongo da idazketa hasi duen bezeroari arrakasta izan duen baieztapena bidali aurretik. Planteamendu horien arteko desberdintasun praktikoa da metodo asinkronoak sareko bi salto behar dituela eta metodo sinkronoak lau behar dituela.

2. trukea: koherentzia

Bi planteamendu hauetan liderren porrota gertatuz gero emaitza ere ezberdina izango da. Lana modu asinkronoan egiten bada, errore hori gertatzen bada, erreplikek ez dituzte erregistro guztiak konprometituko. Zenbat galduko da? Aplikazioaren beraren eta erreplikazioaren eraginkortasunaren araberakoa da. Idatzi erreplikak erreplika lider bihurtzea eragotziko du bertan dagoen informazio kopurua lidergoan baino 1 MB txikiagoa bada, hau da, eragiketa asinkronoan 1 MB erregistro gal daitezke.

Hau ez da modu sinkronikoan gertatzen. Liderrak huts egiten badu, erreplika guztiak eguneratzen dira, lidergoan baieztatutako edozein idazketa errepliketan baieztatu behar baita. Hau koherentzia da.

Jokabide sinkronoak zentzua du fakturazio-aplikazio batean, non koherentziak abantaila argia duen koherentziaren eta errendimenduaren arteko trukean. Horrelako aplikazio baterako garrantzitsuena datuak baliozkoak dira. Pentsa orain sare sozial batean, zeinetan zeregin nagusia erabiltzailearen arreta mantentzea den eskaerei ahalik eta azkarren erantzunez. Kasu honetan, sareko salto gutxiago eta konpromezuetarako itxaron gutxiago dituen errendimendua lehentasuna izango da. Hala ere, errendimenduaren eta koherentziaren arteko trukea ez da pentsatu behar duzun bakarra.

3. trukea: istripuak

Oso garrantzitsua da ulertzea cluster batek nola jokatzen duen porrot batean. Demagun erreplika batek edo gehiagok huts egiten duen egoera bat. Konpromisoak modu asinkronoan prozesatzen direnean, liderrak funtzionatzen jarraituko du, hau da, idazketak onartzen eta prozesatzen ditu, erreplikak falta direnen zain egon gabe. Erreplikak multzora itzultzen direnean, liderra harrapatzen dute. Erreplika sinkronikoarekin, erreplikek erantzuten ez badute, liderrak ez du aukerarik izango eta konpromezuaren berrespenaren zain jarraituko du, erreplika klusterera itzuli eta idazketa onartu eta konprometitu arte.

Konexio bat transakzio bakoitzeko?

Aplikazio bakoitzak koherentzia eta errendimenduaren konbinazio mota desberdina behar du. Ez bada, noski, gure fakturak ordaintzeko aplikazioa, guztiz koherentea dela irudikatzen duguna, edo gure sare sozialen aplikazio ia iragankorra. Gainerako kasuetan, eragiketa batzuk sinkronoak eta beste batzuk asinkronoak izan behar dituzten uneak izango dira. Baliteke sistemak txatera bidalitako mezu bat konprometitu arte itxarotea nahi ez izatea, baina ordainketa bat aplikazio berean prozesatzen bada, orduan itxaron beharko duzu.

Erabaki horiek guztiak, noski, aplikazioen garatzaileak hartzen ditu. Ikuspegi bakoitza noiz erabili jakiteko erabaki egokiak hartzeak zure klusterrei etekinik handiena ateratzen lagunduko dizu. Garrantzitsua da garatzaileak haien artean aldatzea SQL mailan konexioetarako eta transakzioetarako.

Kontrola praktikan bermatzea

Lehenespenez, PostgreSQL-k koherentzia eskaintzen du. Hau zerbitzariaren parametroak kontrolatzen du synchronous_commit. Berez posizioan dago on, baina beste hiru aukera ditu: local, remote_write edo off.

Parametroa ezartzean off konpromiso sinkroniko guztiak gelditzen dira, baita tokiko sisteman ere. Tokiko parametroak sistema lokalerako modu sinkronoa zehazten du, baina errepliketan idazketak modu asinkronoan egiten dira. Remote_write haratago doa: errepliketan idazketak modu asinkronoan egiten dira, baina erreplikak idazketa onartu baina diskoan idatzi ez duenean itzultzen dira.

Eskura dagoen aukerak kontuan hartuta, portaera bat aukeratzen dugu eta, hori kontuan izanda on – grabaketa sinkronoak dira, guk aukeratuko dugu local sarearen bidezko konpromiso asinkronoetarako, tokiko konpromisoak sinkronizatuta utziz.

Orain, hau nola konfiguratu esango dizugu une batean, baina imajinatu konfiguratu dugula synchronous_commit в local zerbitzariarentzat. Parametroa aldatzea posible ote zen galdetu genuen synchronous_commit hegan, eta posible dela ez ezik, bi modu ere badaudela hori egiteko. Lehenengoa zure konexioaren saioa honela ezartzea da:

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

Saioaren ondorengo idazketa guztiek errepliketan egindako idazketak aitortuko dituzte konektatutako bezeroari emaitza positiboa itzuli aurretik. Ezarpena aldatzen baduzu, noski synchronous_commit berriro. Zati bat kendu dezakezu SESSION komandoan balio lehenetsian egongo delako.

Bigarren metodoa ona da transakzio bakar baterako erreplikazio sinkronikoa lortzen duzula ziurtatu nahi duzunean. NoSQL belaunaldiko datu-base askotan transakzioen kontzeptua ez da existitzen, baina bai PostgreSQL-n. Kasu honetan transakzio bat hasten duzu eta gero ezarri synchronous_commit в on transakziorako sarrera exekutatu aurretik. COMMIT transakzioa konprometituko du edozein parametro-balio erabiliz synchronous_commit, garai hartan ezarri zen, nahiz eta hobe den aldagaia aldez aurretik ezartzea, beste garatzaile batzuek idazketak asinkronoak ez direla ulertzen ziurtatzeko.

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

Transakzio-konpromiso guztiak errepliketan idatzita bezala baieztatuko dira datu-baseak konektatutako bezeroari erantzun positiboa eman aurretik.

PostgreSQL konfiguratzea

Honen aurretik, PostgreSQL sistema bat irudikatu genuen synchronous_commit, instalatuta local. Zerbitzariaren aldetik hau errealista izan dadin, bi zerbitzariaren konfigurazio aukera ezarri beharko dituzu. Parametro bat gehiago synchronous_standby_names bere kabuz sartuko da noiz synchronous_commit sartuko da on. Konpromiso sinkronikoetarako zein erreplik diren zehazten du, eta ezarriko dugu *, eta horrek esan nahi du erreplika guztiek parte hartzen dutela. Balio hauek normalean bertan konfiguratzen dira konfigurazio fitxategia gehituz:

synchronous_commit = local  
synchronous_standby_names='*'

Parametroa ezarriz synchronous_commit esanahian sartu local, disko lokalak sinkronoak izaten jarraitzen duen sistema bat sortzen dugu, baina sareko erreplikak asinkronoak diren lehenespenez. Salbu, noski, konpromiso hauek sinkronoak egitea erabakitzen ez badugu, goian erakutsi bezala.

Garapena jarraitu baduzu Gobernadorearen proiektua, baliteke azken aldaketa batzuk nabaritzea (1, 2), eta horri esker, Governor erabiltzaileek parametro hauek probatu eta haien koherentzia kontrolatu ahal izan zituzten.

Hitz batzuk gehiago...

Duela astebete, esango nizuke ezinezkoa dela PostgreSQL hain fin finkatzea. Orduan, Kurt, Konposatu plataformako taldeko kideak, horrelako aukera bazegoela azpimarratu zuen. Nire objekzioak baretu zituen eta PostgreSQL dokumentazioan aurkitu zuen honako hau:

Ezarpen hau edozein unetan alda daiteke. Edozein transakzioren portaera konpromisoaren unean indarrean dagoen ezarpenak zehazten du. Hori dela eta, posible eta erabilgarria da transakzio batzuek modu sinkronikoan konprometitzea eta beste batzuentzat modu asinkronoan. Adibidez, bat behartzeko multistatement transakzioa parametroaren balio lehenetsia kontrakoa denean modu asinkronoan konprometitzeko, ezarri SET LOCAL synchronous_commit TO OFF transakzio batean.

Konfigurazio-fitxategiaren aldaketa txiki honekin, erabiltzaileei beren koherentzia eta errendimenduaren kontrola eman diegu.

Iturria: www.habr.com

PostgreSQL eta konexio espezifikoak idazteko koherentzia ezarpenak