Az írás fordítása kifejezetten a kurzus hallgatói számára készült . Érdekel, hogy ezen a területen fejlődj? Meghívunk a , ahol részletesen bemutatjuk a programot, az online formátum jellemzőit, a kompetenciákat és a karrierlehetőségeket, amelyek a végzősöket várják a képzés után.
A PostgreSQL és a kapcsolat specifikus felvételi konzisztenciájának beállításai
A Compose-nál sok adatbázissal foglalkozunk, és éppen ez ad lehetőséget arra, hogy közelebbről megismerjük a funkcióikat és hátrányait. Ahogy elkezdjük megszeretni az új adatbázisok funkcionális jellemzőit, néha arra gondolunk, milyen jó lenne, ha hasonló funkciók lennének már a régebbi eszközökben is, amelyeket már régóta használunk. Az egyik új jellemző, amelyet szerettünk volna látni a PostgreSQL-ben, a kapcsolat szerint testreszabható felvételi konzisztencia az egész klaszterben. És kiderült, hogy már létezik, és ma szeretnénk megosztani Önnel, hogyan használhatja.
Miért van szükségem erre?
A klaszter működése az alkalmazásától függ. Vegyünk például egy számlafizető alkalmazást. Itt szükség van a 100%-os konzisztenciára a klaszterben, tehát be kell kapcsolnia a szinkronra történő elkötelezettséget, hogy az adatbázis várjon, amíg minden változtatást elvégeznek. Azonban, ha az alkalmazás egy gyorsan fejlődő közösségi média, akkor valószínűleg a 100%-os konzisztenciától gyors válaszidőt részesít előnyben. Ennek elérése érdekében a klaszterében aszinkron elkötelezettségeket használhat.
Ismerkedjen meg a kompromisszussal
Kompromisszumot kell kötnie az adatok konzisztenciája és a teljesítmény között. A PostgreSQL a konzisztenciát részesíti előnyben, mivel az alapértelmezett konfiguráció így kiszámítható és váratlan meglepetések nélkül működik. Most ismerkedjünk meg a kompromisszumokkal.
Kompromisszum 1: Teljesítmény
Ha a PostgreSQL klaszternek nincs szüksége konzisztenciára, akkor teljesen aszinkron módon is működhet. A felvétel a klaszter vezetőjére történik, és a replikák néhány milliszekundum után kapják meg a frissítéseket. Amikor a PostgreSQL klaszternek szüksége van a konzisztenciára, szinkron módban kell működnie. A felvétel a klaszter vezetőjére történik, amely frissítést küld a replikáknak, és megvárja a visszaigazolást arról, hogy minden replikában megtörtént a felvétel, mielőtt visszaigazolná az ügyfélnek, aki elindította a felvételt, hogy az sikeresen megtörtént. A két megközelítés közötti gyakorlati különbség az, hogy az aszinkron módszer két hálózati ugrást igényel, míg a szinkron négyet.
Kompromisszum 2: Konzisztencia
A vezető meghibásodása esetén a két megközelítés kimenetele is eltérő lesz. Ha a munka aszinkron módon folyik, akkor egy ilyen hiba esetén nem minden felvétel kerül rögzítésre a replikákban. Hány adatok fognak elveszni? Ez az alkalmazástól és a replikálás hatékonyságától függ. A Compose replikálás megakadályozza, hogy a replika vezetővé váljon, ha az adatmennyisége 1 Mb-mal kevesebb, mint a vezetőé, azaz potenciálisan legfeljebb 1 Mb felvétel veszhet el aszinkron működés esetén.
Szinkron üzemmódban ez nem történik meg. Ha a vezető hibásodik, akkor minden replikát frissítenek, mivel bármely felvétel, amelyet a vezető megerősített, a replikákban is megerősítést kell, hogy kapjon. Íme a konzisztencia.
A szinkron viselkedésnek értelme van, ha számlafizetési alkalmazásban használják, ahol a konzisztenciának nyilvánvaló előnye van a konzisztencia és a teljesítmény közötti kompromisszumban. A legfontosabb egy ilyen alkalmazás számára az érvényes adatok. Most gondoljon egy közösségi hálóra, ahol a fő feladat a felhasználó figyelmének fenntartása, minél gyorsabb válaszokkal. Ilyen esetben a teljesítmény, kevesebb hálózati ugrással és kevesebb várakozással a kötelezettségvállalásokra, prioritást élvez. Azonban a teljesítmény és a konzisztencia közötti kompromisszum nem az egyetlen, amire gondolni kell.
Kompromisszum 3: Meghibásodások
Nagyon fontos megérteni, hogyan viselkedik a klaszter hiba esetén. Nézzük meg azt a helyzetet, amikor egy vagy több replikáció leáll. Amikor a commitok aszinkron módon vannak feldolgozva, a vezető folytatja a működést, azaz fogadja és feldolgozza a bejegyzéseket anélkül, hogy várna a hiányzó replikákra. Amikor a replikák visszatérnek a klaszterbe, utolérik a vezetőt. Szinkron replikáció esetén, ha a replikák nem válaszolnak, a vezetőnek nem lesz választása, és folytatnia kell a commit megerősítésének várakozását, amíg a replikáció vissza nem tér a klaszterbe, és nem tudja elfogadni és megerősíteni a bejegyzést.
Egy kapcsolat tranzakciónként?
Minden alkalmazásnak különféle összefonódási és teljesítménybeli kombinációra van szüksége. Ha persze nem a számlák kifizetésére szolgáló alkalmazásunkról van szó, amelyet teljesen konzisztensnek képzelünk el, vagy pedig a szinte efemer közösségi médiaalkalmazásunkról. Minden más esetben lesznek olyan pillanatok, amikor bizonyos műveleteknek szinkronosnak, míg másoknak aszinkronosnak kell lenniük. Lehet, hogy nem szeretné, ha a rendszer megvárja, amíg egy csevegésbe küldött üzenetet elmentenek, de ha ugyanebben az alkalmazásban folyik egy kifizetés, akkor várni kell.
Mindezeket a döntéseket természetesen az alkalmazás fejlesztője hozza meg. A helyes döntések arról, hogy mikor alkalmazzanak egy vagy másik megközelítést, segítenek a klaszter maximális kihasználásában. Fontos, hogy a fejlesztő képes legyen váltani közöttük SQL szinten a kapcsolatok és tranzakciók esetén.
A gyakorlatban biztosítva a kontrollt
Alapértelmezés szerint a PostgreSQL biztosítja a konzisztenciát. Ez a szerverparaméter által kontrollált synchronous_commit. Alapértelmezés szerint ez az on, de három másik lehetősége van: local, remote_write vagy off.
Ha a paramétert a off értékre állítjuk, akkor minden szinkron commit leáll, még a helyi rendszerben is. A local paraméter meghatározza a szinkron módot a helyi rendszerben, de a replikákba történő bejegyzések aszinkron módon történnek. A remote_write még tovább megy: a replikákba történő bejegyzések aszinkron módon történnek, de a replikák válaszolnak, amikor a replikáció elfogadta a bejegyzést, de még nem mentette azt le a lemezre.
A rendelkezésre álló opciók figyelembevételével kiválasztjuk a viselkedést, és emlékezve arra, hogy on – ez szinkron bejegyzéseket jelent, választunk local az aszinkron commitokhoz a hálózaton, míg a helyi commitokat szinkronosnak hagyjuk.
Most már elmondjuk, hogyan állíthatja be ezt egy pillanat alatt, de képzelje el, hogy telepítettük synchronous_commit be. local a szerverre. Felmerült bennünk a kérdés, hogy módosítható-e a paraméter synchronous_commit folyamatban, és kiderült, hogy nemcsak lehetséges, hanem ráadásul két módja is van. Az első az, hogy a kapcsolatának session-jét a következőképpen állítja be:
SET SESSION synchronous_commit TO ON;
// Itt vannak a írásokA későbbi írások a session-ben megerősítik az írási műveleteket a replikák számára, mielőtt pozitív eredményt adna a csatlakoztatott kliensnek. Ha persze nem módosítja újra a beállítást synchronous_commit Lehet, hogy elhagyja a SESSION részét a parancsban, mivel az alapértelmezett értékre fog állni.
A második mód jó, ha egyszerűen meg szeretné győződni róla, hogy szinkron replikációt kap egy tranzakcióhoz. Sok „NoSQL” adatbázisban nem létezik tranzakció fogalma, de a PostgreSQL-ben van. Ebben az esetben elindít egy tranzakciót, majd beállítja synchronous_commit be. on a tranzakció írásának végrehajtása előtt. COMMIT megerősíti a tranzakciót, bármilyen paraméter értékét használva, synchronous_commitami abban a pillanatban volt beállítva, bár a legjobb előre beállítani a változót, hogy megbizonyosodjon arról, hogy a többi fejlesztő értse, hogy az írások nem aszinkronok.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Itt vannak a írások
COMMIT; Mostantól a tranzakciók minden megerősítése, mint ahogy a replikákba írták, azt megelőzi, hogy az adatbázis pozitív választ adjon a csatlakoztatott kliensnek.
PostgreSQL beállítása
Ezidáig elképzeltük a PostgreSQL rendszert, amelynek synchronous_commit, telepítve van local. Ahhoz, hogy ez a szerveroldalon valósággá váljon, két konfigurációs paramétert kell beállítania. Egy másik paraméter synchronous_standby_names akkor lép érvénybe, amikor synchronous_commit lesz a on. Meghatározza, hogy mely replikák jogosultak a szinkron commitokra, és be fogjuk állítani *, ami azt jelenti, hogy az összes replikát aktiválni fogja. Ezeket az értékeket általában a a következő hozzáadásával állítják be:
synchronous_commit = local
synchronous_standby_names='*'A synchronous_commit az értékre localparaméter beállításával egy olyan rendszert hozunk létre, amelyben a helyi lemezek szinkronban maradnak, de a hálózati replikák commitjai alapértelmezés szerint aszinkronok. Ha persze nem döntünk úgy, hogy ezek a commitok szinkronok legyenek, ahogy fentebb bemutattuk.
Ha követte a , észrevehették az utóbbi időben történt változásokat (, ), amelyek lehetővé tették a Governor felhasználói számára, hogy teszteljék ezeket a paramétereket és ellenőrizzék azok konzisztenciáját.
Még néhány szó...
Még egy héttel ezelőtt azt mondtam volna, hogy lehetetlen ilyen részletességgel konfigurálni a PostgreSQL-t. Ekkor Kurt, a Compose platformcsapatának tagja, ragaszkodott ahhoz, hogy erre van lehetőség. Megnyugtatta az ellenérveimet, és megtalálta a PostgreSQL dokumentációban :
Ez a paraméter bármikor megváltoztatható. Bármely tranzakció viselkedését a commit során érvényes beállítás határozza meg. Ezért lehetséges és hasznos, hogy bizonyos tranzakciók commitjai szinkron módon, mások pedig aszinkron módon történjenek. Például, hogy egy multistatement tranzakció aszinkron commitot végezzen, amikor az alapértelmezett paraméter értéke éppen az ellenkezője, állítsa be a SET LOCAL synchronous_commit TO OFF további tranzakción belül.
Egy ilyen apró módosítással a konfigurációs fájlban lehetővé tettük a felhasználók számára, hogy ellenőrizzék konzisztenciájukat és teljesítményüket.
Forrás: habr.com
