Beskriva replikering och logisk avkodning

Slutförd

Med parametern wal_level kan du definiera hur mycket information som ska skrivas till loggen. Det finns två alternativ: LOGISK eller REPLIK. REPLICA är standardvärdet. Den här parametern anges när servern startas.

Hög tillgänglighet

Hög tillgänglighet är en Azure Database for PostgreSQL-tjänst som tillhandahåller en väntelägesserver som är redo att ta över om det uppstår ett fel på liveservern. Hög tillgänglighet i Azure Database for PostgreSQL – flexibel server använder replikering för att automatiskt uppdatera väntelägesservern med dataändringar.

När du konfigurerar hög tillgänglighet för flexibel Azure Database for PostgreSQL-server placeras den primära servern i en tillgänglighetszon och en väntelägesserver skapas i en annan tillgänglighetszon. Data replikeras från den primära servern till väntelägesservern med postgreSQL-direktuppspelningsreplikering i synkront läge.

Varje tillgänglighetszon består av ett eller flera datacenter. Tillgänglighetszoner har egna strömförsörjningar, kylsystem, nätverksinfrastruktur osv., vilket gör dem oberoende av varandra. Tre kopior av datafiler och wal-filer (write-ahead log) lagras på lokalt redundant lagring i varje tillgänglighetszon, vilket ger fysisk isolering mellan primära servrar och väntelägesservrar. Om en tillgänglighetszon misslyckas fortsätter de andra två troligen att fungera. Tillgänglighetszoner i en region är anslutna via snabba fibernätverk med svarstid tur och retur på mindre än 2 millisekunder.

Kommentar

Alla regioner har inte tillgänglighetszoner.

Med hög tillgänglighet dupliceras data hela tiden databasen används, vilket ger en uppdaterad kopia av originalet. Om det uppstår en krasch kan repliken användas i stället för originalet. Replikeringen har en primär server och en väntelägesserver . Den primära servern skickar WAL-loggfiler till väntelägesservern , som tar emot WAL-loggfilerna.

Väntelägesservern rapporterar tillbaka till den primära servern med information, till exempel den senaste loggen för framåtskrivning som skrevs, och den sista positionen tömdes på disk osv. Ange parametern wal_receiver_status_interval för att definiera den lägsta frekvensen för WAL-mottagaren att skicka tillbaka en rapport. Parametern max_replication_slots definierar det maximala antalet replikeringsplatser som servern kan stödja. När wal_level är inställt på REPLICA måste max_replication_slots vara minst en, men det tillåtna värdeintervallet är mellan och 0 och 262 143.

Parametern max_wal_senders anger det maximala antalet WAL-avsändare.

De primära servrarna och väntelägesservrarna övervakas och lämpliga åtgärder vidtas för att åtgärda problem som att utlösa en redundansväxling till väntelägesservern. Följande listar zonredundanta statusar för hög tillgänglighet:

• Initiering – i färd med att skapa en ny väntelägesserver.
• Replikering – Datareplikeringen är i stabilt tillstånd och felfri.
• Felfri – Vänteläget uppdateras av den primära.
• Redover – Den primära databasservern håller på att redväxas till vänteläge.
• Tar bort vänteläge – håller på att ta bort väntelägesservern.
• Inte aktiverat – Zonredundant hög tillgänglighet är inte aktiverat.

Du kan lägga till hög tillgänglighet för en befintlig databasserver. Om du aktiverar eller inaktiverar hög tillgänglighet på en liveserver utför du åtgärden när det är lite aktivitet.

Från Azure-portalen:

1. Gå till Din Azure Database for PostgreSQL-server.
2. I avsnittet Översikt väljer du din aktuella konfiguration. Avsnittet Compute + Storage visas.
3. Under Hög tillgänglighet markerar du kryssrutan Hög tillgänglighet (zonredundant) för att aktivera hög tillgänglighet. Hög tillgänglighet stöds inte för nivån Burstable.

Det är viktigt att observera att hög tillgänglighet är ett alternativ för haveriberedskap. Du kan inte använda väntelägesservern i något annat syfte, till exempel att tillåta åtkomst till skrivskyddade databaser. Du kan dock konfigurera replikering mellan två Azure Database for PostgreSQL-servrar med en utgivar- och prenumerantmodell. Den här konfigurationen underhåller två servrar med data som replikeras mellan dem. Du har sedan fullständig åtkomst till prenumerantservern och kan använda databaserna för valfritt ändamål. Du övar den här konfigurationen i övningen i slutet av den här modulen.

Logisk avkodning

Logisk avkodning använder också data som skickas till loggen för framåtskrivning. Som namnet antyder avkodar det posterna i loggen för att göra dem begripliga. Alla ändringar av INSERT, UPDATE och DELETE är tillgängliga för logisk avkodning.

Logisk avkodning kan användas för granskning, analys eller någon annan anledning till att du kanske är intresserad av att veta vad som har ändrats och när det ändrades.

Logisk avkodning extraherar ändringar från alla tabeller i databasen. Den skiljer sig från replikeringen eftersom den inte kan skicka dessa ändringar till en annan PostgreSQL-instanser. I stället tillhandahåller ett PostgreSQL-tillägg ett plugin-program för utdata för att strömma ändringarna.

Med logisk avkodning kan innehållet i loggen för framåtskrivning avkodas till ett format som är lätt att förstå, vilket kan tolkas utan kunskap om databasstrukturen. Azure Database for PostgreSQL stöder logisk avkodning med hjälp av wal2json-tillägget , som är installerat på Azure Database for Postgres-servrar.

Andra tillägg kan användas, till exempel pglogical-tillägget, som tillåter logisk direktuppspelningsreplikering.

Om du vill använda logisk avkodning anger du i Serverparametrar:

• wal_level till LOGISK
• max_replication_slots = 10
• max_wal_senders = 10

Servern måste startas om när ändringarna har gjorts.

Så här använder du det pglogical tillägget från Azure Portal:

1. Gå till Din Azure Database for PostgreSQL-server.
2. Välj Serverparametrar och sök efter shared_preload_libraries. Välj pglogical i listrutan.
3. Sök efter azure.extensions. Välj pglogical i listrutan.
4. Starta om servern om du vill tillämpa ändringarna.

Du måste också ge administratörsanvändaren behörighet för replikering:

ALTER ROLE <adminname> WITH REPLICATION;

Mer information finns i onlinedokumentationen för pglogical extension.

Logisk avkodning matar ut dataändringar som en ström som kallas ett logiskt replikeringsfack.

1. Varje fack har ett plugin-program för utdata som du kan definiera.
2. Varje fack innehåller ändringar från endast en databas, men en databas kan ha flera platser.
3. Varje dataändring genereras normalt en gång per fack.
4. Om PostgreSQL startas om kan ett fack generera ändringar igen, som klienten måste hantera.
5. Fack måste övervakas. Obekräftade platser håller fast vid alla WAL-filer för dessa obekräftade ändringar. Den här situationen kan leda till att lagringen är full eller att transaktions-ID omsluts.