Překlad článku byl připraven speciálně pro studenty kurzu "Databáze". Máte zájem se tímto směrem rozvíjet? Zveme vás na Den otevřených dveří, kde se podrobně bavíme o programu, vlastnostech online formátu, kompetencích a kariérních vyhlídkách, které absolventy po zaškolení čekají.

PostgreSQL a nastavení konzistence zápisu specifické pro připojení
V Compose se zabýváme mnoha databázemi, což nám dává možnost se blíže seznámit s jejich funkčností a nedostatky. Když se učíme milovat funkce nových databází, někdy začínáme přemýšlet o tom, jak by bylo hezké, kdyby podobné funkce byly přítomny ve vyspělejších nástrojích, se kterými pracujeme již dlouhou dobu. Jednou z nových funkcí, kterou jsem chtěl v PostgreSQL vidět, byla konfigurovatelná konzistence zápisu na připojení v celém clusteru. A jak se ukazuje, už ho máme a dnes se s vámi chceme podělit o informace, jak ho můžete využít.

Proč to potřebuji?

Jak by se měl cluster chovat, závisí na vaší aplikaci. Vezměte si například aplikaci pro platby faktur. Budete potřebovat XNUMX% konzistenci v celém clusteru, takže budete muset povolit synchronní potvrzení, aby vaše databáze čekala na provedení všech změn. Pokud je však vaše aplikace rychle se rozvíjející sociální sítí, pak pravděpodobně upřednostníte rychlou odezvu před XNUMX% konzistencí. Chcete-li toho dosáhnout, můžete ve svém clusteru použít asynchronní potvrzení.

Setkat se s kompromisem

Musíte udělat kompromisy mezi konzistencí dat a výkonem. PostgreSQL ustupuje od konzistence, protože výchozí konfigurace je pak předvídatelná a bez nečekaných překvapení. Nyní se podívejme na kompromisy.

Kompromis 1: Výkon

Pokud cluster PostgreSQL nevyžaduje konzistenci, může běžet asynchronně. Zápis je proveden do vedoucího clusteru a aktualizace budou odeslány do jeho replik o několik milisekund později. Když cluster PostgreSQL vyžaduje konzistenci, musí běžet synchronně. Zápis bude proveden vedoucímu klastru, který odešle aktualizaci replik a počká na potvrzení, že každý provedl zápis, než odešle klientovi, který zápis inicioval, že bylo úspěšné. Praktický rozdíl mezi těmito přístupy je v tom, že asynchronní metoda vyžaduje dva skoky v síti, zatímco synchronní metoda vyžaduje čtyři.

Kompromis 2: Konzistence

Výsledek v případě selhání lídra v těchto dvou přístupech bude také odlišný. Pokud je práce prováděna asynchronně, pak pokud dojde k takové chybě, nebudou replikami potvrzeny všechny záznamy. Kolik se ztratí? Záleží na samotné aplikaci a účinnosti replikace. Replikace skládání zabrání tomu, aby se replika stala lídrem, pokud je množství informací v ní o 1 MB menší než v odkazu, to znamená, že během asynchronní operace může být potenciálně ztracen až 1 MB záznamů.

V synchronním režimu k tomu nedochází. Pokud odkaz selže, všechny repliky se aktualizují, protože jakýkoli zápis potvrzený na odkazu musí být potvrzen na replikách. To je konzistence.

Synchronní chování má smysl ve fakturační aplikaci, kde má konzistence jasnou výhodu v kompromisu mezi konzistencí a výkonem. Nejdůležitější pro takovou aplikaci jsou platná data. Nyní přemýšlejte o sociální síti, ve které je hlavním úkolem udržet pozornost uživatele tím, že co nejrychleji odpovídá na požadavky. V tomto případě bude prioritou výkon s menším počtem skoků v síti a kratším čekáním na potvrzení. Kompromis mezi výkonem a konzistencí však není jediný, na který musíte myslet.

Kompromis 3: Pády

Je velmi důležité pochopit, jak se klastr chová během selhání. Zvažte situaci, kdy jedna nebo více replik selže. Když jsou odevzdání zpracovávána asynchronně, bude leader nadále fungovat, tj. přijímat a zpracovávat zápisy, aniž by čekal na chybějící repliky. Když se repliky vrátí do shluku, dohoní vůdce. Pokud při synchronní replikaci repliky neodpovídají, vedoucí nebude mít na výběr a bude nadále čekat na potvrzení potvrzení, dokud se replika nevrátí do klastru a nebude moci přijmout a potvrdit zápis.

Jedno připojení na transakci?

Každá aplikace potřebuje jiný typ kombinace konzistence a výkonu. Pokud to samozřejmě není naše aplikace pro placení účtů, kterou si představujeme jako zcela konzistentní, nebo naše téměř pomíjivá aplikace pro sociální sítě. Ve všech ostatních případech nastanou situace, kdy některé operace musí být synchronní a některé asynchronní. Možná nebudete chtít, aby systém čekal na potvrzení zprávy odeslané do chatu, ale pokud je platba zpracována ve stejné aplikaci, budete muset počkat.

Všechna tato rozhodnutí samozřejmě dělá vývojář aplikace. Správná rozhodnutí o tom, kdy použít jednotlivé přístupy, vám pomohou vytěžit ze svého clusteru maximum. Je důležité, aby mezi nimi vývojář mohl přepínat na úrovni SQL pro připojení a pro transakce.

Zajištění kontroly v praxi

Ve výchozím nastavení poskytuje PostgreSQL konzistenci. To je řízeno parametrem serveru synchronous_commit. Ve výchozím nastavení je na pozici on, ale má tři další možnosti: local, remote_write nebo off.

Při nastavení parametru na off všechna synchronní potvrzení jsou zastavena, dokonce i na lokálním systému. Lokální parametr určuje synchronní režim pro místní systém, ale zápisy do replik se provádějí asynchronně. Remote_write jde ještě dále: zápisy do replik jsou prováděny asynchronně, ale jsou vráceny, když replika zápis přijala, ale nezapsala jej na disk.

Po zvážení dostupného rozsahu možností volíme chování a máme to na paměti on – jedná se o synchronní nahrávky, vybereme local pro asynchronní potvrzení po síti, zatímco místní potvrzení budou synchronní.

Nyní vám za chvíli řekneme, jak to nastavit, ale představte si, že jsme nastavili synchronous_commit в local pro server. Zajímalo nás, zda je možné parametr změnit synchronous_commit za běhu a ukázalo se, že je to nejen možné, ale existují dokonce dva způsoby, jak to udělat. První je nastavit relaci vašeho připojení následovně:

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

Všechny následující zápisy v relaci potvrdí zápisy do replik, než vrátí pozitivní výsledek připojenému klientovi. Pokud samozřejmě nezměníte nastavení synchronous_commit znovu. Část můžete vynechat SESSION v příkazu, protože bude ve výchozí hodnotě.

Druhá metoda je dobrá, když se chcete ujistit, že získáte synchronní replikaci pro jednu transakci. V mnoha databázích generace NoSQL koncept transakcí neexistuje, ale v PostgreSQL ano. V tomto případě zahájíte transakci a poté nastavíte synchronous_commit в on před provedením záznamu pro transakci. COMMIT potvrdí transakci pomocí libovolné hodnoty parametru synchronous_commit, který byl v té době nastaven, i když je nejlepší nastavit proměnnou předem, abyste se ujistili, že ostatní vývojáři pochopili, že zápisy nejsou asynchronní.

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

Všechna potvrzení transakce budou nyní potvrzena jako zapsaná do replik předtím, než databáze vrátí kladnou odpověď připojenému klientovi.

Konfigurace PostgreSQL

Předtím jsme si představili systém PostgreSQL s synchronous_commit, nainstalovaný v local. Aby to bylo na straně serveru realistické, budete muset nastavit dvě možnosti konfigurace serveru. Ještě jeden parametr synchronous_standby_names přijde na své, když synchronous_commit bude v on. Určuje, které repliky jsou vhodné pro synchronní odevzdání, a my to nastavíme *, což bude znamenat, že jsou zapojeny všechny repliky. Tyto hodnoty jsou obvykle konfigurovány v konfigurační soubor přidáváním:

synchronous_commit = local  
synchronous_standby_names='*'

Nastavením parametru synchronous_commit do smyslu localvytváříme systém, kde lokální disky zůstávají synchronní, ale potvrzování síťových replik je ve výchozím nastavení asynchronní. Pokud se ovšem nerozhodneme provést tyto odevzdání synchronně, jak je ukázáno výše.

Pokud jste sledovali vývoj Projekt guvernéra, možná jste si všimli některých nedávných změn (1, 2), což uživatelům Governor umožnilo testovat tyto parametry a sledovat jejich konzistenci.

Ještě pár slov...

Ještě před týdnem bych vám řekl, že je nemožné vyladit PostgreSQL tak jemně. Tehdy Kurt, člen týmu platformy Compose, trval na tom, že taková příležitost existuje. Uklidnil mé námitky a našel v dokumentaci PostgreSQL následující:

Toto nastavení lze kdykoli změnit. Chování jakékoli transakce je určeno nastavením platným v době potvrzení. Proto je možné a užitečné pro některé transakce potvrzovat synchronně a pro jiné asynchronně. Například donutit jednoho multistatement transakce provést potvrzení asynchronně, když je výchozí hodnota parametru opačná, set SET LOCAL synchronous_commit TO OFF v transakci.

Touto malou úpravou konfiguračního souboru jsme dali uživatelům kontrolu nad jejich konzistencí a výkonem.

Zdroj: www.habr.com