PostgreSQL strömmande replikering vs logisk replikering

Jag anser mig vara lite av en upptäcktsresande. I vissa saker vill säga. Jag kommer vanligtvis alltid att beställa samma mat från en bekant restaurang av rädsla för besvikelse uppväger min oro för att prova något nytt.

Och naturligtvis, en hungrig människa tenderar att bara äta eller hur?

Ändå, när det kommer till teknik, i synnerhet SQL (PostgreSQL), tenderar jag att snubbla i full fart (min definition av att utforska) till ofta, obekanta områden, med hopp om att lära mig. Finns det något bättre sätt att lära än att uppleva?

Så vad i hela friden har detta tjafs att göra med logisk replikering och strömmande replikering i PostgreSQL?

Jag är en nybörjare inom dessa områden med noll kunskap. Ja, jag har ungefär lika stor förståelse för detta område av Postgres som jag har inom astrofysik.

Nämnde jag att jag hade noll kunskap?

Därför ska jag i det här blogginlägget försöka smälta skillnaderna i dessa typer av replikering. Utan praktisk erfarenhet från den verkliga världen kan jag inte lova dig "Be all end all ' manuskript för replikering.

Sannolikt skulle andra som är mindre bevandrade inom detta område (som jag själv) dra nytta av det här blogginlägget.

Erfarna användare och utvecklare följer med på resan, jag hoppas att vi ses i kommentarerna nedan.

Ett par basdefinitioner

Vad betyder replikering i vid mening?

Replikering enligt definition på Wiktionary har detta att säga:

"Process genom vilken ett föremål, person, plats eller idé kan kopieras, efterlikna eller reproduceras."

Ändå är det 5:e listade objektet mer tillämpligt på det här blogginlägget och jag tycker att vi bör titta på det också:

"(dator) Processen där elektronisk data ofta kopierar en databas i en dator eller server till en databas i en annan så att alla användare delar samma informationsnivå. Används för att förbättra systemets feltolerans."

Nu finns det något vi kan komma in på. Nämnandet av att kopiera data från en server eller databas till en annan? Vi är i bekant territorium nu...

Så, om vi lägger till vad vi vet från den definitionen, vilka är definitionerna av strömmande replikering och logisk replikering?

Låt oss se vad PostgreSQL Wiki har att erbjuda:

Strömmande replikering:"ger möjligheten att kontinuerligt skicka och applicera WAL XLOG-posterna på ett antal standby-servrar för att hålla dem aktuella.

Och PostgreSQL-dokumentationen har denna definition för logisk replikering:

"Logisk replikering är en metod för att replikera dataobjekt och deras ändringar, baserat på deras replikeringsidentitet (vanligtvis en primärnyckel). Vi använder termen logisk i motsats till fysisk replikering, som använder exakta blockadresser och byte-för-byte-replikering. "

Kapitel 19.6 Replikering från den officiella dokumentationen är också full av godsaker, så var säker och besök den källan.

Nedan ska jag försöka förmedla skillnaderna i lekmans termer. (Kom ihåg att om jag snubblar är jag en nybörjare.) Det här är en extrem översikt på "hög nivå".

Logisk replikering

En "källa"-databas skapar en PUBLICATION med kommandot CREATE PUBLICATION. (Jag tänker på detta i enkla termer som "avsändaren".)

Dokumentationen benämner den som utgivare.

Den här utgivardatabasen har de data vi vill replikera. Ändå måste vi ha något att replikera till och det är här utgivarens motsvarighet(er) kommer in. "prenumeranten". Lägg märke till att jag slängde in en alternativ pluralform eftersom det jag har hittat genom onlinesökningar är praktiskt att ha flera prenumeranter.

En "prenumerant" (kan också ses som replikdatabasen) skapar en PRENUMERATION på en "källa"-databas (utgivare) som definierar anslutningsinformation och alla publikationer den prenumererar på.

Det är möjligt för en prenumerant att också vara en utgivare och skapa sin egen PUBLIKATION som andra prenumeranter kan prenumerera på.

Vad händer nu?

Eventuella dataändringar som sker på utgivaren skickas till prenumeranten. Vilket ur lådan är allt, men kan konfigureras eller begränsas till vissa operationer (t.ex. INFOGA, UPPDATERA eller DELETE).

Exempel på hög nivå:

Anta att vi uppdaterar en rad eller flera rader på en viss tabell i utgivaren, dessa uppdateringar och ändringar replikeras, på abonnentens instans eller flera prenumeranter om den typen av konfiguration är implementerad.

Här är några saker att komma ihåg som jag kände mig värd att nämna:

• Utgivardatabasens wal_level-konfiguration måste ställas in på logisk.
• Logisk replikering har inga DDL-kommandon (Data Definition Language).
• Från sidan Konflikter i dokumentationen:"Logisk replikering fungerar på samma sätt som normala DML-operationer genom att data uppdateras även om de ändrades lokalt på abonnentnoden. Om inkommande data bryter mot några begränsningar kommer replikeringen att stoppas. Detta hänvisas till som en konflikt. När du replikerar UPDATE- eller DELETE-operationer kommer saknad data inte att skapa en konflikt och sådana operationer hoppas helt enkelt över."
• Utgivartabeller måste ha ett sätt att identifiera sig själva (kallad "replikidentitet") för att korrekt replikera DML-operationer (UPDATERA och DELETE) i alla replik(er) för de berörda raderna. Om tabellen har en primärnyckel är detta standard (för mig verkar det som ljudvalet), men i avsaknad av en primärnyckel finns andra konfigurationsalternativ tillgängliga. Hela raden skulle kunna användas om ingen annan kandidatnyckel existerar (benämnt "full"), även om dokumentationen nämner att detta vanligtvis inte är en effektiv lösning. (Se avsnittet REPLICA IDENTITY i dokumenten för en beskrivning på lägre nivå av hur du ställer in den)

Begränsningar

Dokumentationen i avsnitt 31.4. Restriktioner har några viktiga påminnelser om begränsningar som jag kommer att tappa bort. Var säker och granska den länkade sidan ovan för exakta ordspråk.

• Databasschema och eventuella DDL-kommandon stöds inte i replikeringen. Det föreslås att pg_dump kanske skulle kunna användas initialt, men ändå skulle du behöva uppdatera eventuella ytterligare ändringar och framsteg i schemat till alla replikerna själv.
• Datan i sekvenskolumner kommer att replikeras. Men själva sekvensen skulle bara återspegla startvärdet. För läsning är det okej. Men om detta är ditt val för failover, skulle du behöva UPPDATERA till det aktuella värdet själv. Dokumenten föreslår pg_dump här.
• Truncate stöds inte ännu.
• Replikering av stora objekt stöds inte.
• Visningar, materialiserade vyer, partitionsrottabeller eller främmande tabeller stöds inte av varken utgivaren eller prenumeranten.

Rapporterade vanliga användningsfall

• Du är bara intresserad av vissa data och dataändringar som du faktiskt replikerar jämfört med att bara replikera hela databasen.
• När du behöver replik(er) för skrivskyddade operationer, till exempel ett analysscenario.
• Att tillåta användare eller olika undergrupper av användare begränsad eller övervakad åtkomst till data.
• Distribuerar data.
• Kompatibilitet med andra PostgreSQL-versioner.

Strömmande replikering

Från att forska, läsa och studera strömmande replikering, en sak jag samlar på mig direkt, är att välja att ställa in antingen asynkron (standard) eller synkron replikering.

Ah, mer obekanta termer va?

Här är min "högnivå" definition av båda:

Med asynkron replikering, efter att en transaktion har genomförts på den primära, finns det en liten fördröjning när samma transaktion genomförs och skrivs på repliken. Det finns risk för dataförlust med denna typ av konfiguration.

• Ett, anta att mastern kraschar.
• Två, replikerna ligger så långt efter mastern att de har förkastat nödvändiga data och information för att replikerna ens ska vara "aktuella".

Vid synkron replikering anses dock ingen transaktion vara avslutad förrän den har bekräftats av både huvud- och replikservern. Vilket kommer att ha skrivit en commit till båda serverns WAL.

I termer som jag förstår betyder det att skrivningar på mastern också har bekräftats och skrivits på repliken.

Här är den officiella förklaringen från avsnitt 26.2.8. Synkron replikering i den officiella dokumentationen:

"När man begär synkron replikering, kommer varje commit av en skrivtransaktion att vänta tills bekräftelse tas emot att commit har skrivits till skriv-framåtloggningsdisken på både den primära och standby-servern. "

En annan passage från dokumentationen har en bra sammanfattning av vad som måste vara (enligt min mening), en enorm fördel:"Den enda möjligheten att data kan gå förlorad är om både den primära och standby-enheten drabbas av kraschar samtidigt."

Även om ingenting är omöjligt, är det fortfarande en ganska bra garanti för att du inte kommer att lämnas utan någon kopia av dina data.

Okej, vi vet att vi måste välja en av dessa installationskonfigurationer men vad är den övergripande kärnan?

I ett nötskal, Streaming Replication skickar och applicerar WAL-filer (Write Ahead Log) från en databasserver (huvud eller primär), till en "replika" (mottagande databas).

Men det finns en varning här att tänka på. Eventuellt kan WAL-filerna från mastern återvinnas innan standy har fått dem. Ett sätt att mildra detta är att öka inställningen wal_keep_segments till ett högre värde.

Poäng på strömmande replikering

• Som standard är strömmande replikering asynkron, vilket innebär att det finns en fördröjning (kanske liten) mellan de genomförda transaktionerna på mastern och deras synlighet på repliken.
• Replika(er) ansluter till mastern via en nätverksanslutning.
• Var uppmärksam på autentisering. Se här från dokumentationen:"Det är mycket viktigt att åtkomstbehörigheterna för replikering ställs in så att endast betrodda användare kan läsa WAL-strömmen eftersom det är lätt att extrahera privilegierad information från den"

När ska man använda strömmande replikering

• En vanlig användning (särskilt inom analys) tillhandahåller en "skrivskyddad" replik för att ta bort belastningen från den primära servern.
• Du behöver en miljö med hög tillgänglighet.
• Användbar installation för failover till hot standby-server om den primära skulle gå ner.