Översättningen av artikeln är särskilt utarbetad för studenter i kursen «Databaser». Är du intresserad av att utvecklas inom detta område? Vi inbjuder dig till Öppet Hus, där vi går igenom programmet, funktionerna i onlineformatet, kompetenserna och karriärmöjligheterna som väntar studenter efter avslutad utbildning.

PostgreSQL och inställningar för skrivkonsistens för varje specifik anslutning
Hos Compose hanterar vi många databaser, vilket ger oss möjlighet att lära känna deras funktionalitet och brister. När vi lär oss att uppskatta de funktionella egenskaperna hos nya databaser, börjar vi ibland tänka på hur bra det skulle vara om sådana funktioner också fanns i mer mogna verktyg vi redan har arbetat länge med. En av de nya funktionerna som vi ville se i PostgreSQL var anpassningsbar skrivkonsistens per anslutning i hela klustret. Och som det visade sig har vi redan den funktionen, och idag vill vi dela med oss av information om hur du kan använda den.

Varför skulle jag behöva detta?

Hur ett kluster ska bete sig beror på din applikation. Låt oss ta ett exempel med en faktureringsapplikation. Du kommer att behöva hundraprocentig konsistens i klustret, så du måste aktivera synkrona commits så att din databas väntar tills alla ändringar har registrerats. Men om din applikation är ett snabbt växande socialt nätverk, föredrar du förmodligen snabb respons snarare än hundraprocentig konsistens. För att uppnå detta kan du använda asynkrona commits i ditt kluster.

Låt oss introducera kompromissen

Du måste göra en kompromiss mellan datakonsistens och prestanda. PostgreSQL rör sig bort från konsistens, eftersom standardkonfigurationen då blir förutsägbar och utan oväntade överraskningar. Och nu ska vi bekanta oss med kompromisserna.

Kompromiss 1: Prestanda

Om PostgreSQL-klustret inte behöver konsistens kan det fungera asynkront. Skrivning görs till klustrets ledare, och dess repliker får uppdateringar efter några millisekunder. När PostgreSQL-klustret kräver konsistens måste det fungera synkront. Skrivning kommer att göras i klustrets ledare, som skickar uppdateringen till replikerna och väntar på bekräftelse från varje replika att den har genomfört skrivningen, innan den skickar bekräftelsen till klienten som initierade skrivningen om att den har genomförts framgångsrikt. Den praktiska skillnaden mellan dessa tillvägagångssätt är att den asynkrona metoden kräver två nätverkshopp, medan den synkrona kräver fyra.

Kompromiss 2: Konsistens

Resultatet vid ett fel i ledaren i dessa två tillvägagångssätt kommer också att vara olika. Om arbetet utförs asynkront, kommer inte alla skrivningar att bekräftas av replikerna vid ett sådant fel. Hur mycket kommer gå förlorat? Det beror på själva applikationen och effektiviteten i replikationen. Compose-replikeringen förhindrar att en replika blir ledare om mängden information i den är 1 MB mindre än i ledaren, vilket innebär att upp till 1 MB skrivningar potentiellt kan gå förlorade vid asynkront arbete.

I synkront läge sker detta inte. Om ledaren fallerar, uppdateras alla repliker eftersom varje skrivning som bekräftats på ledaren måste bekräftas i replikerna. Det här är konsistensen.

Synkront beteende är meningsfullt att använda i en applikation för räkning, där konsistens har en uppenbar fördel i strävan att hitta en kompromiss mellan konsistens och prestanda. Det viktigaste för en sådan applikation är giltiga data. Tänk nu på ett socialt nätverk, där huvuduppgiften är att behålla användarens uppmärksamhet genom att svara på förfrågningar så snabbt som möjligt. I sådana fall kommer prestanda med färre nätverkshopp och mindre väntetid för commits att prioriteras. Men kompromissen mellan prestanda och konsistens är inte den enda som man behöver tänka på.

Kompromiss 3: Fel

Det är mycket viktigt att förstå hur en kluster beter sig vid fel. Låt oss tänka oss en situation där en eller flera repliker slutar fungera. När förändringar hanteras asynkront kommer ledaren att fortsätta fungera, det vill säga ta emot och bearbeta poster utan att vänta på de saknade replikarna. När replikarna återvänder till klustret kommer de att komma ikapp ledaren. Vid synkron replikering, om replikarna inte svarar, har ledaren inget val utan kommer att fortsätta vänta på bekräftelse av åtagandet tills replikarna återvänder till klustret och kan ta emot och bekräfta posten.

En anslutning per transaktion?

Varje applikation behöver en speciell typ av kombination av konsistens och prestanda. Om den inte är vår faktureringsapplikation, som vi föreställer oss som helt konsistent, eller vår nästan flyktiga sociala medieapp. I alla andra fall kommer det att finnas stunder när vissa operationer måste vara synkrona och andra asynkrona. Du kanske inte vill att systemet ska vänta tills ett meddelande som skickats i chatten har bekräftats, men om en betalning görs i samma applikation, måste det vänta.

Alla dessa beslut tas självklart av applikationsutvecklaren. Rätt beslut om när man ska använda den ena eller andra metoden kommer att hjälpa till att utnyttja klustret maximalt. Det är viktigt att utvecklaren kan växla mellan dem på SQL-nivå för anslutningar och transaktioner.

Att säkerställa kontroll i praktiken

Som standard säkerställer PostgreSQL konsistens. Detta kontrolleras av serversparametern synchronous_commit. Som standard ligger den i läget on, men den har tre andra alternativ: local, remote_write eller off.

När parametern ställs in på off stoppas alla synkrona åtaganden, även i det lokala systemet. Parametern i local definierar det synkrona läget för det lokala systemet, men poster skrivs till replikarna asynkront. Remote_write går ännu längre: poster skrivs till replikarna asynkront, men returneras när replican har tagit emot posten, men inte skrivit den på disk.

Genom att överväga de tillgängliga alternativen väljer vi beteendet och med tanke på att on – det är synkrona poster, kommer vi att välja local för asynkrona åtaganden över nätverket, medan lokala åtaganden förblir synkrona.

Nu ska vi berätta för dig hur du ställer in detta på ett ögonblick, men föreställ dig att vi har installerat synchronous_commit på local servern. Vi undrade om det var möjligt att ändra inställningen synchronous_commit i realtid, och det visade sig att det inte bara är möjligt, utan det finns till och med två sätt att göra det. Det första är att ställa in sessionen för din anslutning på följande sätt:

SET SESSION synchronous_commit TO ON;  
// Ditt skrivande här

Alla efterföljande skrivningar i sessionen kommer att bekräfta skrivoperationer för repliker innan de returnerar ett positivt resultat till den anslutna klienten. Om du förstås inte ändrar inställningen synchronous_commit igen. Du kan utelämna delen SESSION i kommandot, eftersom den kommer att vara i standardvärdet.

Det andra sättet är bra om du bara vill vara säker på att du får synkron replikering för en enda transaktion. I många 'NoSQL'-databaser finns det ingen begrepp om transaktioner, men det finns en i PostgreSQL. I det här fallet påbörjar du en transaktion och ställer sedan in synchronous_commit på on innan du utför skrivoperationen för transaktionen. COMMIT kommer att bekräfta transaktionen med vilket värde parameter synchronous_commit, som var inställt vid den tidpunkten, även om det är bäst att ställa in variabeln i förväg för att säkerställa att andra utvecklare förstår att skrivningar inte är asynkrona.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Ditt skrivande här
COMMIT;  

Alla transaktionskommittéer kommer nu att bekräftas som skrivna till repliker innan databasen returnerar ett positivt svar till den anslutna klienten.

Inställning av PostgreSQL

Tidigare har vi föreställt oss ett PostgreSQL-system med synchronous_commit, installerat på local. För att detta ska vara verkligt på serversidan måste du göra två serverkonfigurationsinställningar. En annan parameter synchronous_standby_names trädde i kraft när synchronous_commit är i on. Den definierar vilka repliker som har rätt till synkrona kommittéer, och vi kommer att ställa in den till *, vilket kommer att innebära att alla repliker är aktiverade. Dessa värden justeras vanligtvis i konfigurationsfilen genom att lägga till:

synchronous_commit = local  
synchronous_standby_names='*'

Genom att ställa in parametern synchronous_commit till värdet local, skapar vi ett system där lokala diskar förblir synkrona, men kommittéer av nätverksrepliker är asynkrona som standard. Om vi inte förstås beslutar att göra dessa kommittéer synkrona, som visat ovan.

Om du har följt utvecklingen av projektet Governor, du kanske har lagt märke till några nyliga förändringar (1, 2), som har möjliggjort för användare av Governor att testa dessa alternativ och övervaka deras konsistens.

Lite mer…

För bara en vecka sedan skulle jag ha sagt att det var omöjligt att finjustera PostgreSQL så noggrant. Just då påpekade Kurt, en medlem av Compose-plattformsteamet, att det faktiskt är möjligt. Han tystade mina invändningar och hittade i PostgreSQL-dokumentationen följande:

Denna inställning kan ändras när som helst. Beteendet för alla transaktioner bestäms av inställningen som gäller vid commit. Därför kan det vara både möjligt och fördelaktigt att för vissa transaktioner effectueras commits synkront, medan för andra – asynkront. Till exempel, för att få en multistatement transaktion att utföra commits asynkront när standardvärdet motsätter sig detta, sätt: SET LOCAL synchronous_commit TO OFF i transaktionen.

Med en sådan liten modifiering i konfigurationsfilen har vi gett användarna möjlighet att styra sin konsistens och prestanda.

Källa: habr.com