Logisk replikering och logisk avkodning i Azure Database for PostgreSQL – flexibel server

Azure Database for PostgreSQL – flexibel server stöder följande logiska dataextraherings- och replikeringsmetoder:

  1. Logisk replikering

    1. Använda postgreSQL-intern logisk replikering för att replikera dataobjekt. Logisk replikering ger dig detaljerad kontroll över datareplikeringen, inklusive datareplikering på tabellnivå.
    2. Använd det pglogical-tillägget som tillhandahåller logisk direktuppspelningsreplikering och fler funktioner, till exempel kopiering av databasens ursprungliga schema, stöd för TRUNCATE, möjlighet att replikera DDL med mera.

  2. Logisk avkodning som implementeras genom avkodning av innehållet i loggen för framåtskrivning (WAL).

Jämför logisk replikering och logisk avkodning

Logisk replikering och logisk avkodning har flera likheter. De båda:

  • Gör att du kan replikera data från Postgres.

  • Använd logg för skrivning i förväg (WAL) som källa för ändringar.

  • Använd logiska replikeringsfack för att skicka ut data. Ett fack representerar en ström av ändringar.

  • Använd en tabells replikidentitetsegenskap för att avgöra vilka ändringar som kan skickas ut.

  • Replikera inte DDL-ändringar.

De två teknikerna har sina skillnader:

Logisk replikering:

  • Gör att du kan ange en tabell eller uppsättning tabeller som ska replikeras.

Logisk avkodning:

  • Extraherar ändringar i alla tabeller i en databas.

Förutsättningar för logisk replikering och logisk avkodning

  1. Gå till sidan parametrar i portalen.

  2. Ange parametern wal_level till logical.

  3. Om du vill använda ett pglogical-tillägg söker du efter parametrarna shared_preload_libraries och azure.extensions och väljer pglogical i listrutan.

  4. Uppdatera max_worker_processes parametervärdet till minst 16. Annars kan du stöta på problem som WARNING: out of background worker slots.

  5. Spara ändringarna och starta om servern för att tillämpa ändringarna.

  6. Bekräfta att din Azure Database for PostgreSQL flexibla servern tillåter nätverkstrafik från din anslutande resurs.

  7. Ge administratörsanvändaren replikeringsbehörigheter.

    ALTER ROLE <adminname> WITH REPLICATION;

  8. Kontrollera att den roll som du använder har behörigheter för schemat som du replikerar. Annars kan du stöta på fel som Permission denied for schema.

Anmärkning

Det är alltid bra att skilja replikeringsanvändaren från det vanliga administratörskontot.

Använda logisk replikering och logisk avkodning

Att använda intern logisk replikering är det enklaste sättet att replikera data från din Azure Database for PostgreSQL flexibla servern. Du kan använda SQL-gränssnittet eller direktuppspelningsprotokollet för att använda ändringarna. Du kan också använda SQL-gränssnittet för att ta del av ändringar genom logisk avkodning.

Inbyggd logisk replikering

Logisk replikering använder termerna utgivare och prenumerant.

  • Publiceraren är den Azure Database for PostgreSQL Flexible Server-databas som skickar data.
  • Prenumerant är databasen i Azure Database for PostgreSQL Flexible Server som tar emot data.

Här är exempelkod som du kan använda för att testa logisk replikering.

  1. Anslut till utgivardatabasen. Skapa en tabell och lägg till data.

    CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);
INSERT INTO basic VALUES (1, 'apple');
INSERT INTO basic VALUES (2, 'banana');

  2. Skapa en publikation för tabellen.

    CREATE PUBLICATION pub FOR TABLE basic;

  3. Anslut till prenumerantdatabasen. Skapa en tabell med samma schema som på publiceraren.

    CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);

  4. Skapa en prenumeration som ansluter till publikationen som du skapade tidigare.

    CREATE SUBSCRIPTION sub CONNECTION 'host=<server>.postgres.database.azure.com user=<rep_user> dbname=<dbname> password=<password>' PUBLICATION pub;

  5. Nu kan du göra en sökning på tabellen på prenumeranten. Du ser att den tar emot data från utgivaren.

    SELECT * FROM basic;

    Du kan lägga till fler rader i utgivarens tabell och visa ändringarna för prenumeranten.

    Om du inte kan se data växlar du till en användare som är medlem i azure_pg_admin rollen och kontrollerar tabellinnehållet.

Mer information om logisk replikering finns i PostgreSQL-dokumentationen.

Använda logisk replikering mellan databaser på samma server

Om du vill konfigurera logisk replikering mellan olika databaser på samma Azure Database for PostgreSQL flexibel server följer du specifika riktlinjer för att undvika implementeringsbegränsningar. För närvarande kan du bara skapa en prenumeration som ansluter till samma databaskluster om replikeringsplatsen inte skapas inom samma kommando. Annars fastnar CREATE SUBSCRIPTION anropet vid en LibPQWalReceiverReceive väntehändelse. Det här beteendet beror på en befintlig begränsning i Postgres-motorn, som kan tas bort i framtida versioner.

Följ dessa steg för att konfigurera logisk replikering mellan dina "käll- och måldatabaser" på samma server samtidigt som du undviker den här begränsningen:

Skapa först en tabell med namnet basic med ett identiskt schema i både käll- och måldatabaserna:

-- Run this on both source and target databases
CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);

I källdatabasen skapar du sedan en publikation för tabellen och skapar separat ett logiskt replikeringsfack med hjälp pg_create_logical_replication_slot av funktionen. Den här metoden hjälper till att förhindra problemet med att processen hänger sig, vilket vanligtvis uppstår när sloten skapas i samma kommando som prenumerationen. Använd plugin-programmet pgoutput :

-- Run this on the source database
CREATE PUBLICATION pub FOR TABLE basic;
SELECT pg_create_logical_replication_slot('myslot', 'pgoutput');

Skapa sedan en prenumeration på den tidigare skapade publikationen i måldatabasen. Ställ in create_slot på false för att förhindra att din flexibla Azure Database for PostgreSQL-server skapar en ny plats, och ange det platsnamn som du skapade i föregående steg. Innan du kör kommandot ersätter du platshållarna i anslutningssträng med dina faktiska databasautentiseringsuppgifter:

-- Run this on the target database
CREATE SUBSCRIPTION sub
   CONNECTION 'dbname=<source dbname> host=<server>.postgres.database.azure.com port=5432 user=<rep_user> password=<password>'
   PUBLICATION pub
   WITH (create_slot = false, slot_name='myslot');

När du har konfigurerat den logiska replikeringen testar du den genom att infoga en ny post i tabellen i källdatabasen basic och sedan verifiera att den replikeras till måldatabasen:

-- Run this on the source database
INSERT INTO basic SELECT 3, 'mango';

-- Run this on the target database
TABLE basic;

Om allt är korrekt konfigurerat ser du den nya posten från källdatabasen i måldatabasen, vilket bekräftar att den logiska replikeringen har konfigurerats korrekt.

pglogical-tillägg

Här är ett exempel på hur du konfigurerar pglogical på providerdatabasservern och prenumeranten. Mer information finns i dokumentationen om pglogical extension. Kontrollera också att du slutför de nödvändiga uppgifter som angavs tidigare.

  1. Installera det pglogical tillägget i databasen på både providern och prenumerantdatabasservrarna.

    \c myDB
CREATE EXTENSION pglogical;

  2. Om replikeringsanvändaren inte är serveradministrationsanvändaren (användaren som skapade servern) beviljar du användaren medlemskap i azure_pg_admin rollen och tilldelar replikerings- och INLOGGNINGsattributen till användaren. Mer information finns i pglogical-dokumentationen .

    GRANT azure_pg_admin to myUser;
ALTER ROLE myUser REPLICATION LOGIN;

  3. På providerdatabasservern (källa/utgivare) skapar du providernoden.

    select pglogical.create_node( node_name := 'provider1',
dsn := ' host=myProviderServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>');

  4. Skapa en replikeringsuppsättning.

    select pglogical.create_replication_set('myreplicationset');

  5. Lägg till alla tabeller i databasen i replikeringsuppsättningen.

    SELECT pglogical.replication_set_add_all_tables('myreplicationset', '{public}'::text[]);

    Som en alternativ metod kan du också lägga till tabeller från ett specifikt schema (till exempel testUser) till en standardreplikeringsuppsättning.

    SELECT pglogical.replication_set_add_all_tables('default', ARRAY['testUser']);

  6. Skapa en prenumerantnod på prenumerantdatabasservern .

    select pglogical.create_node( node_name := 'subscriber1',
dsn := ' host=mySubscriberServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>' );

  7. Skapa en prenumeration för att starta synkroniseringen och replikeringsprocessen.

    select pglogical.create_subscription (
subscription_name := 'subscription1',
replication_sets := array['myreplicationset'],
provider_dsn := 'host=myProviderServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>');

  8. Verifiera prenumerationsstatusen.

    SELECT subscription_name, status FROM pglogical.show_subscription_status();

Försiktighet

Pglogical stöder för närvarande inte automatisk DDL-replikering. Du kan kopiera det ursprungliga schemat manuellt med hjälp pg_dump --schema-onlyav . Du kan köra DDL-instruktioner på leverantören och prenumeranten samtidigt med funktionen pglogical.replicate_ddl_command. Tänk på andra begränsningar i tillägget som anges här.

Logisk avkodning

Du kan använda logisk avkodning via strömningsprotokollet eller SQL-gränssnittet.

Direktuppspelningsprotokoll

Att konsumera ändringar via strömningsprotokollet är ofta att föredra. Du kan skapa din egen konsument eller anslutning, eller använda en tredjepartstjänst som Debezium.

Ett exempel som använder strömningsprotokollet med pg_recvlogicalfinns i wal2json-dokumentationen: ett exempel som använder strömningsprotokollet med pg_recvlogical.

SQL-gränssnitt

I följande exempel använder du SQL-gränssnittet med plugin-programmet wal2json.

  1. Skapa ett fack.

    SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');

  2. Utfärda SQL-kommandon. Till exempel:

    CREATE TABLE a_table (
   id varchar(40) NOT NULL,
   item varchar(40),
   PRIMARY KEY (id)
);

INSERT INTO a_table (id, item) VALUES ('id1', 'item1');
DELETE FROM a_table WHERE id='id1';

  3. Tillämpa ändringarna.

    SELECT data FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'pretty-print', '1');

    Utdata ser ut så här:

    {
      "change": [
      ]
}
{
      "change": [
               {
                        "kind": "insert",
                        "schema": "public",
                        "table": "a_table",
                        "columnnames": ["id", "item"],
                        "columntypes": ["character varying(40)", "character varying(40)"],
                        "columnvalues": ["id1", "item1"]
               }
      ]
}
{
      "change": [
               {
                        "kind": "delete",
                        "schema": "public",
                        "table": "a_table",
                        "oldkeys": {
                              "keynames": ["id"],
                              "keytypes": ["character varying(40)"],
                              "keyvalues": ["id1"]
                        }
               }
      ]
}

  4. Lämna platsen när du är klar med att använda den.

    SELECT pg_drop_replication_slot('test_slot');

Mer information om logisk avkodning finns i PostgreSQL-dokumentationen: logisk avkodning.

Monitor

Du måste övervaka logisk avkodning. Släpp alla oanvända replikeringsfack. Replikeringsplatser behåller Postgres WAL-loggar och relevanta systemkataloger tills ändringarna har lästs av. Om din prenumerant eller konsument misslyckas eller är felaktigt konfigurerad samlas de okonsumerade loggarna på hög och fyller upp lagringsutrymmet. Dessutom ökar oförbrukade loggar risken för transaktions-ID-omslag. Båda situationerna kan göra att servern blir otillgänglig. Därför måste du fortlöpande konsumera logiska replikeringsplatser. Om ett logiskt replikeringsfack inte längre används släpper du det omedelbart.

Kolumnen active i vyn pg_replication_slots visar om en konsument är ansluten till en plats.

SELECT * FROM pg_replication_slots;

Ange aviseringar för måtten Maximalt använda transaktions-ID och Lagringsanvändning för att meddela dig när värdena ökar över normala tröskelvärden.

Begränsningar

  • Begränsningar för logisk replikering gäller enligt beskrivningen här.

  • Platser och HA-redundansväxling – I PostgreSQL 16 och tidigare versioner bevaras inte logiska replikeringsplatser vid redundansväxlingar när servrar med hög tillgänglighet (HA) används med Azure Database for PostgreSQL. För att bibehålla logiska replikeringsplatser och säkerställa datakonsekvens efter en failover använder du tillägget PG Failover Slots och konfigurerar relaterade inställningar, såsom hot_standby_feedback = on. Mer information om hur du aktiverar det här tillägget finns i dokumentationen.

Stöd för redundans för logiska replikeringsplatser

För PostgreSQL 17 och senare versioner stöds facksynkronisering internt. Om du aktiverar rätt PostgreSQL-konfigurationer (sync_replication_slots, hot_standby_feedback) bevaras logiska replikeringsfack automatiskt efter redundansväxlingen och inget tillägg krävs.

Viktigt!

Du måste släppa det logiska replikeringsfacket på den primära servern om motsvarande prenumerant inte längre finns. Annars ackumuleras WAL-filerna i den primära filen och fyller lagringen. Den primära servern växlar automatiskt till skrivskyddat läge när lagringsanvändningen når 95 procent, eller när den tillgängliga kapaciteten är mindre än 5 GiB. Om lagringströskelvärdet överskrider en viss gräns och det logiska replikeringsfacket inte används (på grund av en icke-tillgänglig prenumerant) släpper Azure Database for PostgreSQL flexibla servern automatiskt det oanvända logiska replikeringsfacket. Den åtgärden släpper ackumulerade WAL-filer och undviker att servern blir otillgänglig på grund av att lagringen blir fylld.

Relaterat innehåll

  • Last updated on