Artikli tõlge koostati spetsiaalselt kursuse üliõpilastele "Andmebaas". Kas olete huvitatud selles suunas arenemisest? Kutsume teid üles Avatud uste päev, kus räägime üksikasjalikult programmist, veebivormingu omadustest, kompetentsidest ja karjäärivõimalustest, mis koolilõpetajaid pärast koolitust ees ootavad.

PostgreSQL ja ühendusepõhised kirjutamise järjepidevuse sätted
Composes tegeleme paljude andmebaasidega, mis annab võimaluse nende funktsionaalsuse ja puudustega lähemalt tutvuda. Uute andmebaaside funktsioone armastama õppides hakkame mõnikord mõtlema, kui tore oleks, kui sarnased funktsioonid oleksid olemas ka küpsemates tööriistades, millega oleme pikka aega töötanud. Üks uutest funktsioonidest, mida tahtsin PostgreSQL-is näha, oli konfigureeritav kirjutamise järjepidevus ühenduse kohta kogu klastri ulatuses. Ja nagu selgub, on see meil juba olemas ja täna tahame teiega jagada teavet selle kohta, kuidas seda kasutada.

Miks ma seda vajan?

See, kuidas klaster peaks käituma, sõltub teie rakendusest. Võtame näiteks arvete tasumise rakenduse. Teil on vaja XNUMX% järjepidevust kogu klastris, nii et peate lubama sünkroonsed sissekanded, et teie andmebaas ootaks kõigi muudatuste tegemist. Kui aga teie rakendus on kiiresti kasvav sotsiaalvõrgustik, eelistate tõenäoliselt kiiret reageerimist XNUMX% järjepidevusele. Selle saavutamiseks saate oma klastris kasutada asünkroonseid kohustusi.

Leidke kompromiss

Peate tegema kompromisse andmete järjepidevuse ja jõudluse vahel. PostgreSQL eemaldub järjepidevusest, kuna vaikekonfiguratsioon on siis etteaimatav ja ootamatute üllatusteta. Vaatame nüüd kompromisse.

Kompromiss 1: jõudlus

Kui PostgreSQL-klaster ei nõua järjepidevust, võib see töötada asünkroonselt. Kirjutamine tehakse klastri juhile ja värskendused saadetakse selle koopiatele mõni millisekund hiljem. Kui PostgreSQL-klaster nõuab järjepidevust, peab see töötama sünkroonselt. Kirjutamine tehakse klastri juhile, kes saadab koopiatele värskenduse ja ootab kinnitust, et igaüks neist on kirjutanud, enne kui saadab kirjutamise algatanud kliendile kinnituse, et see õnnestus. Praktiline erinevus nende lähenemisviiside vahel seisneb selles, et asünkroonne meetod nõuab kahte võrguhüpet, sünkroonne meetod aga nelja.

Kompromiss 2: järjepidevus

Nende kahe lähenemisviisi puhul on juhi ebaõnnestumise korral ka tulemus erinev. Kui töö tehakse asünkroonselt, siis sellise tõrke ilmnemisel ei seo koopiad kõiki kirjeid. Kui palju läheb kaduma? Oleneb rakendusest endast ja replikatsiooni efektiivsusest. Koostamise replikatsioon takistab koopia muutumist liidriks, kui selles on 1 MB vähem teavet kui juht, see tähendab, et asünkroonse töö käigus võib kaduda kuni 1 MB kirjeid.

Sünkroonrežiimis seda ei juhtu. Kui juht ebaõnnestub, värskendatakse kõiki koopiaid, kuna kõik juhile kinnitatud kirjutised peavad olema koopiatel kinnitatud. See on järjepidevus.

Sünkroonne käitumine on mõttekas arveldusrakenduses, kus järjepidevusel on järjepidevuse ja jõudluse vahelises kompromissis selge eelis. Sellise rakenduse puhul on kõige olulisemad kehtivad andmed. Mõelge nüüd sotsiaalsele võrgustikule, mille peamine ülesanne on hoida kasutaja tähelepanu, vastates päringutele nii kiiresti kui võimalik. Sel juhul on prioriteediks jõudlus väiksema võrguhüppega ja vähema täitmistega ootamisega. Kuid jõudluse ja järjepidevuse vaheline kompromiss pole ainus, millele peate mõtlema.

3. kompromiss: kokkujooksmised

Väga oluline on mõista, kuidas klaster rikke ajal käitub. Mõelge olukorrale, kus üks või mitu koopiat ebaõnnestuvad. Kui kohustusi töödeldakse asünkroonselt, jätkab juht toimimist, st võtab vastu ja töötleb kirjutisi, ootamata puuduvaid koopiaid. Kui koopiad klastrisse naasevad, jõuavad nad liidrile järele. Sünkroonse replikatsiooni korral, kui koopiad ei reageeri, ei ole juhil valikut ja ta ootab edasiandmise kinnitust, kuni koopia naaseb klastrisse ning saab kirjutamise vastu võtta ja sisse viia.

Üks ühendus tehingu kohta?

Iga rakendus vajab erinevat tüüpi järjepidevuse ja jõudluse kombinatsiooni. Kui see pole muidugi meie arvete maksmise rakendus, mida me ette kujutame olevat täiesti järjepidev, või meie peaaegu lühiajaline suhtlusvõrgustiku rakendus. Kõigil muudel juhtudel on aegu, mil mõned toimingud peavad olema sünkroonsed ja mõned asünkroonsed. Te ei pruugi soovida, et süsteem ootaks, kuni vestlusesse saadetud sõnum on vastu võetud, kuid kui makset töödeldakse samas rakenduses, peate ootama.

Kõik need otsused teeb loomulikult rakenduse arendaja. Õigete otsuste tegemine selle kohta, millal iga lähenemisviisi kasutada, aitab teil oma klastrist maksimumi võtta. On oluline, et arendaja saaks nende vahel ühenduste ja tehingute jaoks SQL-tasemel vahetada.

Kontrolli tagamine praktikas

Vaikimisi tagab PostgreSQL järjepidevuse. Seda juhib serveri parameeter synchronous_commit. Vaikimisi on see asendis on, kuid sellel on veel kolm võimalust: local, remote_write või off.

Kui määrate parameetri väärtusele off kõik sünkroonsed sissekanded peatatakse, isegi kohalikus süsteemis. Kohalik parameeter määrab kohaliku süsteemi sünkroonrežiimi, kuid replikatesse kirjutamine toimub asünkroonselt. Remote_write läheb veelgi kaugemale: replikatesse kirjutamine toimub asünkroonselt, kuid tagastatakse siis, kui koopia on kirjutamise vastu võtnud, kuid pole seda kettale kirjutanud.

Arvestades saadaolevaid valikuvõimalusi, valime käitumise ja seda silmas pidades on – need on sünkroonsed salvestised, me valime local võrgu kaudu asünkroonsete sissekannete jaoks, jättes samal ajal kohalikud kohustused sünkroonseks.

Nüüd räägime teile, kuidas seda hetke pärast seadistada, kuid kujutage ette, et me seadistame synchronous_commit в local serveri jaoks. Mõtlesime, kas parameetrit on võimalik muuta synchronous_commit käigu pealt ja selgus, et see pole mitte ainult võimalik, vaid selleks on isegi kaks võimalust. Esimene on ühenduse seansi seadistamine järgmiselt.

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

Kõik järgnevad seansi kirjutamised kinnitavad koopiatele tehtud kirjutamisi enne positiivse tulemuse tagastamist ühendatud kliendile. Kui te muidugi seadet ei muuda synchronous_commit uuesti. Võite osa välja jätta SESSION käsus, sest see on vaikeväärtuses.

Teine meetod on hea, kui soovite lihtsalt veenduda, et saate ühe tehingu jaoks sünkroonse replikatsiooni. Paljudes NoSQL-i genereerimise andmebaasides pole tehingute mõistet olemas, kuid PostgreSQL-is on see olemas. Sel juhul alustate tehingut ja seejärel määrate synchronous_commit в on enne tehingu kande tegemist. COMMIT sooritab tehingu mis tahes parameetri väärtusega synchronous_commit, mis oli sel ajal määratud, kuigi kõige parem on muutuja eelnevalt seadistada, et teised arendajad saaksid aru, et kirjutamine ei ole asünkroonne.

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

Kõik tehingute sõlmimised kinnitatakse nüüd koopiatesse kirjutatuks, enne kui andmebaas tagastab ühendatud kliendile positiivse vastuse.

PostgreSQL-i seadistamine

Enne seda kujutasime ette PostgreSQL-süsteemi synchronous_commit, paigaldatud sisse local. Selle serveri poolel realistlikuks muutmiseks peate määrama kaks serveri konfiguratsioonivalikut. Veel üks parameeter synchronous_standby_names tuleb ise millal synchronous_commit tuleb sisse on. See määrab, millised koopiad on sobilikud sünkroonseks kinnitamiseks, ja me määrame selle *, mis tähendab, et kaasatud on kõik koopiad. Need väärtused on tavaliselt konfigureeritud konfiguratsioonifail lisades:

synchronous_commit = local  
synchronous_standby_names='*'

Parameetri määramisega synchronous_commit tähendusse local, loome süsteemi, kus kohalikud kettad jäävad sünkroonseks, kuid võrgu koopiate sissekanded on vaikimisi asünkroonsed. Muidugi välja arvatud juhul, kui me otsustame need toimepanekud sünkroonseks muuta, nagu ülal näidatud.

Kui olete arengut jälginud Kuberneri projekt, võisite märgata hiljutisi muudatusi (1, 2), mis võimaldas kuberneri kasutajatel neid parameetreid testida ja nende järjepidevust jälgida.

Paar sõna veel...

Veel nädal tagasi oleksin teile öelnud, et PostgreSQL-i on võimatu nii peenelt häälestada. Siis väitis Compose platvormi meeskonna liige Kurt, et selline võimalus on olemas. Ta rahustas mu vastuväiteid ja leidis PostgreSQL-i dokumentatsioonist järgmine:

Seda seadet saab igal ajal muuta. Mis tahes tehingu käitumise määrab kinnistamise ajal kehtiv säte. Seetõttu on võimalik ja kasulik osade tehingute sooritamine sünkroonselt ja teiste puhul asünkroonselt. Näiteks ühe sundimiseks multistatement tehing, et teha asünkroonselt toimeid, kui parameetri vaikeväärtus on vastupidine, seatud SET LOCAL synchronous_commit TO OFF tehingus.

Selle konfiguratsioonifaili väikese muudatusega andsime kasutajatele kontrolli nende järjepidevuse ja jõudluse üle.

Allikas: www.habr.com