De oersetting fan it artikel waard spesifyk taret foar de learlingen fan 'e kursus . Ynteressearre yn ûntwikkeling yn dizze rjochting? Wy noegje jo út om , wêr't wy yn detail prate oer it programma, funksjes fan it online formaat, kompetinsjes en karriêreperspektyf dy't ôfstudearden nei training wachtsje.
PostgreSQL en ferbiningsspesifike skriuwkonsistinsjeynstellingen
By Compose dogge wy mei in protte databases, wat ús de kâns jout om mear fertroud te wurden mei har funksjonaliteit en tekoartkommingen. As wy leare om fan 'e funksjes fan nije databases te hâlden, begjinne wy soms te tinken hoe moai it soe wêze as ferlykbere funksjes oanwêzich wiene yn 'e mear folwoeksen ark wêrmei't wy in lange tiid hawwe wurke. Ien fan 'e nije funksjes dy't ik yn PostgreSQL sjen woe, wie konfigurearbere skriuwkonsistinsje per ferbining oer it heule kluster. En sa docht bliken, wy hawwe it al, en hjoed wolle wy diele mei jo ynformaasje oer hoe't jo kinne brûke it.
Wêrom haw ik it nedich?
Hoe't it kluster moat gedrage hinget ôf fan jo applikaasje. Nim, bygelyks, in rekken betelling app. Jo sille XNUMX% konsistinsje nedich hawwe oer it kluster, dus jo moatte syngroane commits ynskeakelje sadat jo databank wachtet op alle wizigingen dy't makke wurde. As jo applikaasje lykwols in rapstgroeiend sosjaal netwurk is, dan sille jo wierskynlik rappe reaksje leaver hawwe boppe XNUMX% konsistinsje. Om dit te berikken kinne jo asynchrone commits brûke yn jo kluster.
Moetsje kompromis
Jo moatte ôfwikseling meitsje tusken gegevenskonsistinsje en prestaasjes. PostgreSQL beweecht fuort fan konsistinsje, om't de standertkonfiguraasje dan foarsisber is en sûnder ûnferwachte ferrassingen. Litte wy no nei de kompromissen sjen.
Tradeoff 1: Prestaasje
As it PostgreSQL-kluster gjin konsistinsje fereasket, kin it asynchronysk rinne. It skriuwen wurdt makke nei de klusterlieder, en updates sille in pear millisekonden letter nei syn replika's stjoerd wurde. As in PostgreSQL-kluster konsistinsje fereasket, moat it syngroan rinne. It skriuwen sil makke wurde oan 'e klusterlieder, dy't in update nei de replika's sil stjoere en wachtsje op befêstiging dat elk skreaun hat foardat befêstiging ferstjoerd wurdt nei de kliïnt dy't it skriuwen hat inisjearre dat it suksesfol wie. It praktyske ferskil tusken dizze oanpakken is dat de asynchrone metoade twa netwurkhops fereasket, wylst de syngroane metoade fjouwer fereasket.
Tradeoff 2: Konsistinsje
It resultaat yn it gefal fan in liedermislearring yn dizze twa oanpakken sil ek oars wêze. As it wurk asynchronysk wurdt útfierd, dan as sa'n flater optreedt, sille net alle records troch de replika's wurde begien. Hoefolle sil ferlern gean? Hinget ôf fan 'e applikaasje sels en de effisjinsje fan replikaasje. Compose replikaasje sil foarkomme dat in replika in lieder wurdt as de hoemannichte ynformaasje dêryn 1 MB minder is as yn 'e lieder, dat is, oant 1 MB oan records kinne mooglik ferlern gean by asynchrone operaasje.
Dit bart net yn syngroane modus. As de lieder mislearret, wurde alle replika's bywurke, om't elk skriuwen befêstige op 'e lieder moat wurde befêstige op' e replika's. Dit is konsistinsje.
Syngroane gedrach makket sin yn in billingapplikaasje wêr't konsistinsje in dúdlik foardiel hat yn 'e kompromis tusken konsistinsje en prestaasjes. It wichtichste ding foar sa'n applikaasje is jildige gegevens. Tink no oer in sosjaal netwurk wêryn de wichtichste taak is om de oandacht fan 'e brûker te hâlden troch sa gau mooglik te reagearjen op oanfragen. Yn dit gefal sil prestaasjes mei minder netwurk hops en minder wachtsje op commits in prioriteit wêze. De kompromis tusken prestaasjes en konsistinsje is lykwols net de iennichste wêr't jo oer moatte tinke.
Trade-off 3: Crashes
It is heul wichtich om te begripen hoe't in kluster gedraacht by in mislearring. Beskôgje in situaasje dêr't ien of mear replika's mislearje. As commits asynchronous wurde ferwurke, sil de lieder fierder funksjonearje, dat is, skriuwt akseptearje en ferwurkje, sûnder te wachtsjen op ûntbrekkende replika's. As de replika's weromkomme nei it kluster, helje se de lieder yn. Mei syngroane replikaasje, as de replika's net reagearje, dan sil de lieder gjin kar hawwe en sil trochgean te wachtsjen op befestigingsbefêstiging oant de replika weromkomt nei it kluster en it skriuwen kin akseptearje en begean.
Ien ferbining per transaksje?
Elke applikaasje hat in oar type kombinaasje fan konsistinsje en prestaasjes nedich. Behalven as it fansels ús rekken-beteljende app is, dy't wy ús foarstelle folslein konsekwint te wêzen, as ús hast ephemere sosjale netwurkapp. Yn alle oare gefallen sille d'r tiden wêze dat guon operaasjes syngroan moatte wêze en guon asyngroan moatte wêze. Jo meie net wolle dat it systeem wachtet oant in berjocht stjoerd nei it petear is ynset, mar as in betelling wurdt ferwurke yn deselde applikaasje, dan moatte jo wachtsje.
Al dizze besluten wurde fansels makke troch de applikaasje-ûntwikkelder. De juste besluten meitsje oer wannear't elke oanpak te brûken sil jo helpe om it measte út jo kluster te heljen. It is wichtich dat de ûntwikkelder kin wikselje tusken harren op it SQL-nivo foar ferbinings en foar transaksjes.
It garandearjen fan kontrôle yn 'e praktyk
Standert leveret PostgreSQL konsistinsje. Dit wurdt regele troch de tsjinner parameter synchronous_commit. Standert is it yn posysje on, mar it hat trije oare opsjes: local, remote_write of off.
By it ynstellen fan de parameter oan off alle syngroane commits wurde stoppe, sels op it lokale systeem. De lokale parameter spesifisearret syngroane modus foar it lokale systeem, mar skriuwt nei replika's wurde asynchronysk útfierd. Remote_write giet noch fierder: skriuwt nei replika's wurde asynchroan makke, mar wurde weromjûn as de replika it skriuwen akseptearre hat, mar it net op skiif skreaun hat.
Troch beskôgje de beskikbere oanbod fan opsjes, wy kieze in gedrach en, hâld yn gedachten dat on - dit binne syngroane opnames, wy sille kieze local foar asynchrone commits oer it netwurk, wylst lokale commits syngroane litte.
No sille wy jo fertelle hoe't jo dit yn in momint kinne ynstelle, mar stel jo foar dat wy ynstelle synchronous_commit в local foar de tsjinner. Wy fregen ús ôf oft it mooglik wie om de parameter te feroarjen synchronous_commit op 'e flecht, en it die bliken dat it net allinnich mooglik is, der binne sels twa manieren om dit te dwaan. De earste is om de sesje fan jo ferbining as folgjend yn te stellen:
SET SESSION synchronous_commit TO ON;
// Your writes go hereAlle folgjende skriuwingen yn 'e sesje sille skriuwingen erkennen oan' e replika's foardat jo in posityf resultaat weromjaan oan 'e ferbûne kliïnt. Utsein as jo de ynstelling feroarje fansels synchronous_commit wer. Jo kinne it diel ferlitte SESSION yn it kommando om't it yn 'e standertwearde sil wêze.
De twadde metoade is goed as jo gewoan wolle soargje dat jo syngroane replikaasje krije foar ien transaksje. Yn in protte NoSQL-generaasje-databases bestiet it konsept fan transaksjes net, mar it docht it yn PostgreSQL. Yn dit gefal begjinne jo in transaksje en dan ynstelle synchronous_commit в on foardat it útfieren fan de yngong foar de transaksje. COMMIT sil de transaksje dwaan mei elke parameterwearde synchronous_commit, dy't op dat stuit ynsteld is, hoewol it it bêste is om de fariabele foarôf yn te stellen om te soargjen dat oare ûntwikkelders begripe dat skriuwingen net asynchronysk binne.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT; Alle transaksje commits sille no wurde befêstige as skreaun oan replika's foardat de databank jout in posityf antwurd oan de ferbûne klant.
PostgreSQL ynstelle
Dêrfoar hawwe wy in PostgreSQL-systeem foarsteld mei synchronous_commit, ynstallearre yn local. Om dit realistysk te meitsjen oan 'e serverkant, moatte jo twa serverkonfiguraasjeopsjes ynstelle. Noch ien parameter synchronous_standby_names sil komme ta syn eigen wannear synchronous_commit sil yn 't wêze on. It bepaalt hokker replika's yn oanmerking komme foar syngroane commits, en wy sille it ynstelle *, wat sil betsjutte dat alle replika's belutsen binne. Dizze wearden wurde normaal konfigureare yn troch ta te heakjen:
synchronous_commit = local
synchronous_standby_names='*'Troch it ynstellen fan de parameter synchronous_commit yn betsjutting local, Wy meitsje in systeem dêr't lokale skiven bliuwe syngroane, mar netwurk replika commits binne asynchronous standert. Behalven as wy fansels beslute om dizze commits syngroan te meitsjen, lykas hjirboppe toand.
As jo de ûntwikkeling hawwe folge , jo hawwe miskien wat resinte feroarings opmurken (, ), wêrtroch Governor-brûkers dizze parameters kinne testen en har konsistinsje kontrolearje.
Noch in pear wurden...
Krekt in wike lyn soe ik jo sein hawwe dat it ûnmooglik is om PostgreSQL sa fyn te fine. Dat is doe't Kurt, lid fan it Compose-platfoarmteam, oanstie dat sa'n kâns bestie. Hy kalmearre myn beswieren en fûn yn 'e PostgreSQL-dokumintaasje :
Dizze ynstelling kin op elk momint wizige wurde. It gedrach foar elke transaksje wurdt bepaald troch de ynstelling dy't jildt op it momint fan commit. Dêrom is it mooglik en nuttich foar guon transaksjes om synchroon te begean en foar oaren asynchronysk. Bygelyks om ien te twingen multistatement transaksje te meitsjen commits asynchronously as de standert wearde fan de parameter is tsjinoerstelde, set SET LOCAL synchronous_commit TO OFF yn in transaksje.
Mei dizze lytse wiziging oan it konfiguraasjetriem joegen wy brûkers kontrôle oer har konsistinsje en prestaasjes.
Boarne: www.habr.com