PostgreSQL-strömning vs logisk replikering – jämförelse

Att replikera informationen som lagras i din databas är avgörande för att distribuera data och säkerställa att du har en säkerhetskopia som kan användas för katastrofåterställning, om något skulle gå fel.

PostgreSQL-replikering finns i två former, och båda har sina nischade användningsområden. Att förstå hur man tillämpar en eller båda av dessa datareplikeringsmetoder kan effektivisera dina datadistributionsprocesser. Det sista du vill är att förlora avgörande arbete du har gjort på en databas.

Låt oss ta en titt på fördelar, nackdelar och användningsfall av strömmande replikering och logiskt i PostgreSQL.

Definiera datareplikering i PostgreSQL

Om du redan är bekant med vad datareplikering är, kan du gå vidare och scrolla ner till nästa avsnitt. Men om du är ny på databasteknik vill vi lägga grunden riktigt snabbt.

Som namnet antyder är replikering processen att ofta kopiera data från en databas i en datorserver till en annan databas på en annan server, så att alla användare har tillgång till samma informationsnivå. Inom datoranvändning används replikering för att eliminera fel i ett digitalt system.

Replikering eliminerar datasilos, skyddar värdefull information och effektiviserar utvecklingen.

I PostgreSQL finns det två alternativ för replikering:logisk och strömmande replikering. Dessa metoder är bra för olika användningsfall, och som utvecklare kan du vara mer benägen att använda den ena framför den andra. Men det är bra att förstå hur man använder båda så att du kan bestämma vilken som ska användas i olika scenarier.

Logisk replikering i PostgreSQL

Streaming replikering introducerades för användning med PostgreSQL v10.0. Logisk replikering fungerar genom att kopiera/replikera dataobjekt och deras ändringar baserat på deras replikeringsidentitet.

I många fall är uppgifternas identitet en primär nyckel. I PostgreSQL ger det användarna finkornig kontroll över replikerad data och informationssäkerhet.

Termen logisk används för att skilja den från fysisk replikering, som använder sig av byte-för-byte-replikering och exakta blockadresser. Läs mer i den officiella PostgreSQL-dokumentationen här.

Genom en publicerings- och prenumerationsmodell fungerar den genom att en eller flera prenumeranter kan prenumerera på en eller flera publikationer på en förlagsnod. Prenumeranterna kan hämta information från publikationerna och återpublicera data för kaskadreplikering eller mer komplex konfiguration.

Logisk datareplikering kan också ta formen av transaktionsreplikering. Om ingenjören vill kopiera en tabell kan de använda denna replikeringsmetod för att ta en ögonblicksbild av data från utgivarens sida och skicka den till prenumerantens databas.

När prenumeranterna gör ändringar i originaldata får utgivardatabasen uppdateringar i realtid. För att säkerställa transaktionsöverensstämmelse i publikationer med en enda prenumeration måste prenumeranten tillämpa uppgifterna i samma ordning som utgivaren.

Fördelar med logisk replikering i PostgreSQL

Logisk replikering gör det möjligt för användare att använda en destinationsserver för skrivningar och tillåter utvecklare att ha olika index och säkerhetsdefinitioner. Detta ger ökad flexibilitet för överföring av data mellan publicister och prenumeranter.

Stöd i flera versioner

Dessutom kommer den med stöd för flera versioner och kan ställas in mellan olika versioner av PostgreSQL. Den tillhandahåller även händelsebaserad filtrering. Publikationer kan ha flera prenumerationer, vilket gör det enkelt att dela data över ett brett nätverk.

Minsta serverbelastning

Jämfört med triggerbaserade lösningar har den en minimal serverbelastning samtidigt som den ger lagringsflexibilitet genom att replikera mindre uppsättningar. Som nämnts ovan kan logisk datareplikering till och med kopiera data som finns i grundläggande partitionerade tabeller.

Det är också viktigt att nämna att logisk datareplikering möjliggör datatransformation även när den ställs in och tillåter parallell streaming mellan utgivare.

Nackdelar med logisk replikering i PostgreSQL

Logisk replikering kopierar inte sekvenser, stora objekt, materialiserade vyer, partitionsrottabeller och främmande tabeller.

I PostgreSQL stöds logisk datareplikering endast av DML-operationer. Utvecklare kan inte använda DDL eller trunkera, och schemat måste definieras i förväg. Dessutom stöder den inte ömsesidig (dubbelriktad) replikering.

Om användare stöter på konflikter med begränsningar på replikerad data i en tabell, kommer replikeringen att sluta. Det enda sättet för replikering att återupptas är om orsaken till konflikten är löst.

En oavsiktlig konflikt kan stoppa ditt teams momentum, så du måste förstå hur du löser eventuella problem snabbt.

Om konflikten inte åtgärdas snabbt kommer replikeringsplatsen att frysa i sitt nuvarande tillstånd, utgivarnoden börjar samla på sig WAL-loggar (Writ-Ahead Logs) och noden kommer så småningom att få slut på diskutrymme.

Användningsfall för logisk replikering i PostgreSQL

Många ingenjörer kommer att använda logisk replikering för:

• Distribuera ändringar inom en enda databas eller databasundergrupp till prenumeranter i realtid
• Sammanslagning av flera databaser till en central databas (ofta för analysanvändning)
• Skapa repliker över olika versioner av PostgreSQL
• Distribuera replikeringar mellan PostgreSQL-instanser över olika plattformar, som Linux till Windows
• Dela replikerad data med andra användare eller grupper
• Distribuera en databasdelmängd mellan flera databaser

Strömmande replikering i PostgreSQL

Streaming replikering introducerades för användning med PostgreSQL 9.0. Processen skickar och tillämpar WAL-filer (Writ-Ahead Logging) från en huvud- eller primär databasserver till en replika eller mottagande databas. WAL:erna används för replikering och för att säkerställa dataintegritet.

Så fungerar strömmande replikering

Strömmande replikering fungerar för att överbrygga klyftan mellan dataöverföringar som är inneboende i filbaserad loggsändning, som väntar tills en WAL når maximal kapacitet för att skicka data.

Genom att strömma WAL-poster streamar databasservrar WAL-poster i bitar för att synkronisera data. Standbyservern ansluter till repliken och tar emot WAL-bitarna när de skickas över.

Med strömmande replikering måste användaren bestämma om den ska ställa in asynkron eller synkron replikering. När strömmande replikering initialt distribueras kommer den som standard till asynkron replikering.

Detta indikerar att det finns en fördröjning mellan den initiala ändringen på den primära och reflektionen av den ändringen på repliken. Asynkronisering öppnar dörren för potentiell dataförlust om mastern kraschar innan ändringarna kopieras eller om repliken är så osynkroniserad med originalet att den redan har kasserat relevant data för att göra ändringar.

Synkron replikering är ett mycket säkrare alternativ eftersom det gör ändringar i realtid. Överföringen från mastern till repliken anses vara ofullständig tills båda servrarna har verifierat informationen. När dataändringarna har bekräftats, registreras överföringen på båda servrarnas WAL.

Oavsett om du använder asynkron eller synkron replikering måste replikerna vara anslutna till mastern via en nätverksanslutning. Dessutom är det viktigt för användarna att ställa in åtkomstprivilegier för replikans WAL-strömmar, så att informationen inte äventyras.

Fördelar med strömmande replikering i PostgreSQL

En av de viktigaste fördelarna med att använda strömmande replikering är att det enda sättet att förlora data är om både den primära och den mottagande servrarna kraschar samtidigt. Om du lämnar ut viktig information garanterar strömmande replikering nästan att en kopia av ditt arbete kommer att sparas.

Användare kan ansluta mer än en standby-server till den primära, och loggarna kommer att strömmas från den primära till var och en av de anslutna standby-serverna. Om en av replikerna är försenad eller kopplas ur, fortsätter streamingen till de andra replikerna.

Att ställa in loggsändning genom strömmande replikering kommer inte att störa något som användaren för närvarande kör på den primära databasen. Om den primära dataservern måste stängas av väntar den tills de uppdaterade posterna har skickats till repliken innan den stängs av.

Nackdelar med strömmande replikering i PostgreSQL

Strömmande replikering kommer inte att kopiera information till en annan version eller arkitektur, ändra standby-servrarnas information och erbjuder inte granulär replikering.

Särskilt med asynkron strömmande datareplikering kan äldre WAL-filer som inte har kopierats till repliken ännu återvinnas när användaren gör ändringar i mastern. För att säkerställa att viktiga filer inte går förlorade kan användaren ställa in wal_keep_segments till ett högre värde.

Utan användarautentiseringsuppgifter inställda för replikservrarna kan det vara lätt att extrahera känslig data. För att realtidsuppdateringar ska ske mellan mastern och repliken måste användaren ändra replikeringsmetoden från standardasynkron replikering till synkron replikering.

Användningsfall för strömmande replikering i PostgreSQL

Många ingenjörer kommer att använda strömmande replikering för:

• Skapa en säkerhetskopia för deras primära databas i händelse av serverfel eller dataförlust
• Första en lösning med hög tillgänglighet med så liten replikeringsfördröjning som möjligt
• Skicka stora frågor för att lindra en del av stressen på det primära systemet
• Fördelning av databasarbetsbelastningar över flera maskiner, särskilt för skrivskyddade format

Vad väntar i framtiden?

PostgreSQL Global Development Group tillkännagav lanseringen av PostgreSQL 14 den 30 september 2021. Den nya versionen kom laddad med uppgraderingar i både streaming och logiska replikeringar genom plattformen.

För strömmande replikering tillåter version 14 användare att:

• Ställ in serverparametern log_recovery_conflict_waits för att rapportera långa väntetider för återställningskonflikt automatiskt
• Pausa återställning på en varm standby-server när du ändrar parametrarna på en primär server (istället för att stänga av standby-läget omedelbart)
• Använd funktionen pg_get_wal_replay_pause_state() för att rapportera återhämtningsläget mer detaljerat
• Ange en skrivskyddad serverparameter in_hot_standby
• Tunkera små tabeller snabbt under återställning på kluster som har ett stort antal delade buffertar
• Tillåt filsystemsynkronisering vid början av kraschåterställning via Linux
• Använd funktionen pg_xact_commit_timestamp_origin() på en specificerad transaktion för att returnera commit-tidsstämpeln och replikeringsursprunget
• Använd funktionen pg_last_committed_xact() för att lägga till replikeringsursprunget på den returnerade posten
• Använd standardfunktionsbehörighetskontroller för att ändra replikeringsursprungsfunktioner (standarden begränsar fortfarande åtkomsten till superanvändarna)

För logisk replikering tillåter version 14 användare att:

• Strömma långa pågående transaktioner till prenumeranter med API:et för logisk replikering
• Tillåt flera transaktioner under tabellreplikering
• Generera omedelbara WAL-logg-undertransaktioner och XID-associationer på toppnivå
• Använd funktionen pg_create_logical_replication_slot() för att förbättra logiska avkodnings-API:er för två-fas commits
• Lägg till meddelanden om ogiltiga cacheminne till WAL när kommandot slutförs för att tillåta logisk streaming av pågående transaktioner
• Kontrollera vilka logiska avkodningsmeddelanden som skickas till replikeringsströmmen
• Använd binärt överföringsläge för snabbare replikeringar
• Filteravkodning med XID

PostgreSQL arbetar redan mot version 15, som är tänkt att släppas under tredje kvartalet 2022. En av problemen med replikering som ska åtgärdas i den senaste versionen inkluderar att förhindra användningen av variabler som ärvs från servermiljön i strömmande replikering. Men när fler användare anpassar sig till version 14 kommer PostgreSQL sannolikt att lägga till fler uppgifter för att förbättra replikeringsfunktionerna.

En snabb jämförelse av PostgreSQL-replikering:logisk vs. strömmande replikering

Slutsats

Vi hoppas att den här guiden kommer till användning när du ställer in dina replikeringsfunktioner. Om du har några frågor eller om det finns något annat du vill veta om hur ScaleGrid kan hjälpa dig med dina PostgreSQL-distributioner, kontakta en av våra många databasexperter.