ProHoster > Blogs > Administrācija > PostgreSQL un savienojumam specifiski rakstīŔanas konsekvences iestatījumi

PostgreSQL un savienojumam specifiski rakstīŔanas konsekvences iestatījumi

Raksta tulkojums tika sagatavots speciāli kursa studentiem "Datu bāze". Vai vēlaties attÄ«stÄ«ties Å”ajā virzienā? Mēs aicinām jÅ«s uz Atvērto durvju diena, kurā mēs detalizēti runājam par programmu, tieÅ”saistes formāta iezÄ«mēm, kompetencēm un karjeras perspektÄ«vām, kas sagaida absolventus pēc apmācÄ«bas.

PostgreSQL un savienojumam specifiski rakstīŔanas konsekvences iestatījumi

PostgreSQL un savienojumam specifiski rakstīŔanas konsekvences iestatījumi
Uzņēmumā Compose mēs strādājam ar daudzām datu bāzēm, kas dod mums iespēju tuvāk iepazÄ«ties ar to funkcionalitāti un trÅ«kumiem. Mācoties iemÄ«lēt jaunu datu bāzu lÄ«dzekļus, mēs dažkārt sākam domāt, cik jauki bÅ«tu, ja lÄ«dzÄ«gas funkcijas bÅ«tu pieejamas nobrieduŔākajos rÄ«kos, ar kuriem esam strādājuÅ”i jau ilgu laiku. Viena no jaunajām funkcijām, ko vēlējos redzēt programmā PostgreSQL, bija konfigurējama rakstÄ«Å”anas konsekvence katram savienojumam visā klasterÄ«. Un, kā izrādās, mums tas jau ir, un Å”odien mēs vēlamies dalÄ«ties ar jums informācijā par to, kā jÅ«s to varat izmantot.

Kāpēc man tas ir vajadzīgs?

Tas, kā klasterim vajadzētu darboties, ir atkarÄ«gs no jÅ«su lietojumprogrammas. Ņemiet, piemēram, rēķinu apmaksas lietotni. Jums bÅ«s nepiecieÅ”ama XNUMX% konsekvence visā klasterÄ«, tāpēc jums bÅ«s jāiespējo sinhronās saistÄ«bas, lai jÅ«su datu bāze gaidÄ«tu visu izmaiņu veikÅ”anu. Tomēr, ja jÅ«su lietojumprogramma ir strauji augoÅ”s sociālais tÄ«kls, jÅ«s, iespējams, dosiet priekÅ”roku ātrai reakcijai, nevis XNUMX% konsekvencei. Lai to panāktu, savā klasterÄ« varat izmantot asinhronās saistÄ«bas.

Iepazīstieties ar kompromisu

Jums ir jāveic kompromisi starp datu konsekvenci un veiktspēju. PostgreSQL attālinās no konsekvences, jo noklusējuma konfigurācija ir paredzama un bez negaidītiem pārsteigumiem. Tagad aplūkosim kompromisus.

Kompromiss 1: veiktspēja

Ja PostgreSQL klasterim nav nepiecieÅ”ama konsekvence, tas var darboties asinhroni. RakstÄ«Å”ana tiek veikta klastera vadÄ«tājam, un atjauninājumi tiks nosÅ«tÄ«ti tā replikām dažas milisekundes vēlāk. Ja PostgreSQL klasterim ir nepiecieÅ”ama konsekvence, tai jādarbojas sinhroni. RakstÄ«Å”ana tiks veikta klastera vadÄ«tājam, kas nosÅ«tÄ«s atjauninājumu replikām un gaidÄ«s apstiprinājumu, ka katrs ir uzrakstÄ«jis, pirms nosÅ«tÄ«s apstiprinājumu klientam, kurÅ” uzsāka rakstÄ«Å”anu, ka tā bija veiksmÄ«ga. Praktiskā atŔķirÄ«ba starp Ŕīm pieejām ir tāda, ka asinhronajai metodei ir nepiecieÅ”ami divi tÄ«kla apiņi, bet sinhronajai metodei nepiecieÅ”ami četri.

2. kompromiss: konsekvence

ArÄ« rezultāts lÄ«dera neveiksmes gadÄ«jumā Å”ajās divās pieejās bÅ«s atŔķirÄ«gs. Ja darbs tiek veikts asinhroni, tad, ja rodas Ŕāda kļūda, kopijas neveic visus ierakstus. Cik daudz tiks zaudēts? AtkarÄ«gs no paÅ”as lietojumprogrammas un replikācijas efektivitātes. RakstÄ«Å”anas replikācija neļaus kopijai kļūt par lÄ«deri, ja informācijas apjoms tajā ir par 1 MB mazāks nekā lÄ«derā, tas ir, asinhronas darbÄ«bas laikā var tikt zaudēts lÄ«dz 1 MB ierakstu.

Sinhronā režīmā tas nenotiek. Ja vadītājs neizdodas, visas kopijas tiek atjauninātas, jo jebkuram vadītājam apstiprinātajam ierakstam ir jābūt apstiprinātam uz replikām. Tā ir konsekvence.

Sinhronai darbÄ«bai ir jēga norēķinu lietojumprogrammā, kur konsekvencei ir skaidra priekÅ”rocÄ«ba kompromisā starp konsekvenci un veiktspēju. VissvarÄ«gākais Ŕādai lietojumprogrammai ir derÄ«gi dati. Tagad padomājiet par sociālo tÄ«klu, kurā galvenais uzdevums ir noturēt lietotāja uzmanÄ«bu, atbildot uz pieprasÄ«jumiem pēc iespējas ātrāk. Å ajā gadÄ«jumā prioritāte bÅ«s veiktspējai ar mazāku tÄ«kla lēcienu skaitu un mazāku gaidÄ«Å”anas laiku, lai izpildÄ«tu saistÄ«bas. Tomēr kompromiss starp veiktspēju un konsekvenci nav vienÄ«gais, par ko jums jādomā.

3. kompromiss: avārijas

Ir ļoti svarÄ«gi saprast, kā klasteris uzvedas neveiksmes laikā. Apsveriet situāciju, kad viena vai vairākas kopijas neizdodas. Kad saistÄ«bas tiek apstrādātas asinhroni, vadÄ«tājs turpinās darboties, tas ir, pieņems un apstrādās ierakstus, negaidot trÅ«kstoŔās kopijas. Kad replikas atgriežas klasterÄ«, tās panāk lÄ«deri. Izmantojot sinhrono replikāciju, ja replikas nereaģē, lÄ«derim nebÅ«s citas izvēles un viņŔ turpinās gaidÄ«t apstiprināŔanas apstiprinājumu, lÄ«dz replika atgriezÄ«sies klasterÄ« un varēs pieņemt un veikt rakstÄ«Å”anu.

Viens savienojums katram darījumam?

Katrai lietojumprogrammai ir nepiecieÅ”ama cita veida konsekvences un veiktspējas kombinācija. Ja vien, protams, tā nav mÅ«su rēķinu apmaksas lietotne, kuru mēs iedomājamies kā pilnÄ«gi konsekventu, vai mÅ«su gandrÄ«z Ä«slaicÄ«gā sociālo tÄ«klu lietotne. Visos citos gadÄ«jumos bÅ«s reizes, kad dažām darbÄ«bām jābÅ«t sinhronām, bet dažām jābÅ«t asinhronām. JÅ«s, iespējams, nevēlaties, lai sistēma gaidÄ«tu, kamēr čatam nosÅ«tÄ«tais ziņojums tiek apstiprināts, taču, ja maksājums tiek apstrādāts tajā paŔā lietojumprogrammā, jums bÅ«s jāgaida.

Visus Å”os lēmumus, protams, pieņem lietojumprogrammas izstrādātājs. Pareizu lēmumu pieņemÅ”ana par to, kad izmantot katru pieeju, palÄ«dzēs jums gÅ«t maksimālu labumu no kopas. Ir svarÄ«gi, lai izstrādātājs varētu pārslēgties starp tiem SQL lÄ«menÄ« savienojumiem un transakcijām.

Kontroles nodroÅ”ināŔana praksē

Pēc noklusējuma PostgreSQL nodroÅ”ina konsekvenci. To kontrolē servera parametrs synchronous_commit. Pēc noklusējuma tas ir pozÄ«cijā on, taču tai ir trÄ«s citas iespējas: local, remote_write vai off.

Iestatot parametru uz off visas sinhronās saistÄ«bas tiek apturētas pat vietējā sistēmā. Vietējais parametrs norāda sinhrono režīmu lokālajai sistēmai, bet ierakstÄ«Å”ana replikās tiek veikta asinhroni. Remote_write iet vēl tālāk: ieraksti replikās tiek veikti asinhroni, bet tiek atgriezti, kad replika ir pieņēmusi rakstÄ«Å”anu, bet nav ierakstÄ«jusi to diskā.

Apsverot pieejamo iespēju klāstu, mēs izvēlamies uzvedÄ«bu un, paturot to prātā on ā€“ tie ir sinhronie ieraksti, mēs izvēlēsimies local asinhronām saistÄ«bām tÄ«klā, vienlaikus atstājot vietējās saistÄ«bas sinhronas.

Tagad mēs jums pateiksim, kā to iestatÄ«t, bet iedomājieties, ka mēs to iestatām synchronous_commit Š² local serverim. Mēs domājām, vai ir iespējams mainÄ«t parametru synchronous_commit lidojumā, un izrādÄ«jās, ka tas ir ne tikai iespējams, bet ir pat divi veidi, kā to izdarÄ«t. Pirmais ir iestatÄ«t savienojuma sesiju Ŕādi:

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

Visi turpmākie ieraksti sesijā apstiprinās ierakstus replikās pirms pozitÄ«va rezultāta atgrieÅ”anas pievienotajam klientam. Ja vien, protams, nemaināt iestatÄ«jumu synchronous_commit atkal. JÅ«s varat izlaist daļu SESSION komandā, jo tā bÅ«s noklusējuma vērtÄ«bā.

Otrā metode ir piemērota, ja vēlaties tikai pārliecināties, ka saņemat sinhronu replikāciju vienam darÄ«jumam. Daudzās NoSQL paaudzes datu bāzēs transakciju jēdziens nepastāv, bet PostgreSQL tas pastāv. Å ajā gadÄ«jumā jÅ«s sākat darÄ«jumu un pēc tam iestatāt synchronous_commit Š² on pirms darÄ«juma ieraksta veikÅ”anas. COMMIT veiks darÄ«jumu, izmantojot jebkuru parametra vērtÄ«bu synchronous_commit, kas tajā laikā tika iestatÄ«ts, lai gan vislabāk ir iestatÄ«t mainÄ«go jau iepriekÅ”, lai pārliecinātos, ka citi izstrādātāji saprot, ka rakstÄ«Å”ana nav asinhrona.

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

Visas transakciju saistības tagad tiks apstiprinātas kā ierakstītas replikās, pirms datubāze atgriezīs pozitīvu atbildi pievienotajam klientam.

PostgreSQL iestatīŔana

Pirms tam mēs iedomājāmies PostgreSQL sistēmu ar synchronous_commit, uzstādÄ«ts iekŔā local. Lai tas bÅ«tu reālistisks servera pusē, jums bÅ«s jāiestata divas servera konfigurācijas opcijas. Vēl viens parametrs synchronous_standby_names nāks pats, kad synchronous_commit bÅ«s on. Tas nosaka, kuras replikas ir piemērotas sinhronai apstiprināŔanai, un mēs to iestatÄ«sim *, kas nozÄ«mēs, ka ir iesaistÄ«tas visas kopijas. Å Ä«s vērtÄ«bas parasti tiek konfigurētas konfigurācijas fails pievienojot: 

synchronous_commit = local  
synchronous_standby_names='*'

Iestatot parametru synchronous_commit nozÄ«mē local, mēs izveidojam sistēmu, kurā lokālie diski paliek sinhroni, bet tÄ«kla replikas pēc noklusējuma ir asinhronas. Ja vien mēs, protams, nenolemjam Ŕīs saistÄ«bas padarÄ«t sinhronas, kā parādÄ«ts iepriekÅ”.

Ja esi sekojis lÄ«dzi attÄ«stÄ«bai Gubernatora projekts, iespējams, esat pamanÄ«jis dažas nesenās izmaiņas (1, 2), kas ļāva Governor lietotājiem pārbaudÄ«t Å”os parametrus un uzraudzÄ«t to konsekvenci.

Vēl daži vārdi...

Tikai pirms nedēļas es jums bÅ«tu teicis, ka PostgreSQL nav iespējams tik precÄ«zi noregulēt. Toreiz Kurts, Compose platformas komandas biedrs, uzstāja, ka Ŕāda iespēja pastāv. ViņŔ nomierināja manus iebildumus un atrada PostgreSQL dokumentācijā Ŕādi:

PostgreSQL un savienojumam specifiski rakstīŔanas konsekvences iestatījumi

Šo iestatījumu var mainīt jebkurā laikā. Jebkura darījuma darbību nosaka iestatījums, kas ir spēkā saistību izpildes laikā. Tāpēc ir iespējams un lietderīgi dažus darījumus veikt sinhroni, bet citus asinhroni. Piemēram, lai piespiestu vienu multistatement transakcija, lai veiktu saistības asinhroni, ja parametra noklusējuma vērtība ir pretēja, iestatīt SET LOCAL synchronous_commit TO OFF darījumā.

Ar Å”o nelielo konfigurācijas faila modifikāciju mēs ļāvām lietotājiem kontrolēt to konsekvenci un veiktspēju.

Avots: www.habr.com

Pievieno komentāru