Logisk avkodning

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – enskild server

Viktigt!

Azure Database for PostgreSQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till Azure Database for PostgreSQL – flexibel server. Mer information om hur du migrerar till Azure Database for PostgreSQL – flexibel server finns i Vad händer med Azure Database for PostgreSQL – enskild server?.

Med logisk avkodning i PostgreSQL kan du strömma dataändringar till externa konsumenter. Logisk avkodning används populärt för scenarier för händelseströmning och ändring av datainsamling.

Logisk avkodning använder ett plugin-program för utdata för att konvertera Postgres WAL-fil (logg som skrivs på förhand) till ett läsbart format. Azure Database for PostgreSQL tillhandahåller utdata-plugin-programmet wal2json, test_decoding och pgoutput. pgoutput görs tillgängligt av PostgreSQL från PostgreSQL version 10 och senare.

En översikt över hur postgres logisk avkodning fungerar finns i vår blogg.

Kommentar

Logisk replikering med PostgreSQL-publikation/prenumeration stöds inte med Azure Database for PostgreSQL – enskild server.

Konfigurera servern

Logisk avkodning och läsrepliker beror båda på postgres-loggen (WAL) för information. Dessa två funktioner behöver olika nivåer av loggning från Postgres. Logisk avkodning behöver en högre loggningsnivå än läsrepliker.

Om du vill konfigurera rätt loggningsnivå använder du azure-replikeringssupportparametern. Stöd för Azure-replikering har tre inställningsalternativ:

  • Av – Placerar minst information i WAL. Den här inställningen är inte tillgänglig på de flesta Azure Database for PostgreSQL-servrar.
  • Replik – mer utförlig än Av. Det här är den lägsta loggningsnivån som krävs för att läsrepliker ska fungera. Den här inställningen är standard på de flesta servrar.
  • Logiskt – mer utförligt än replik. Det här är den lägsta loggningsnivån för att logisk avkodning ska fungera. Läsrepliker fungerar också med den här inställningen.

Använda Azure CLI

  1. Ange azure.replication_support till logical.

    az postgres server configuration set --resource-group mygroup --server-name myserver --name azure.replication_support --value logical

  2. Starta om servern för att tillämpa ändringen.

    az postgres server restart --resource-group mygroup --name myserver

  3. Om du kör Postgres 9.5 eller 9.6 och använder åtkomst till offentligt nätverk lägger du till brandväggsregeln för att inkludera klientens offentliga IP-adress där du ska köra den logiska replikeringen. Namnet på brandväggsregeln måste innehålla _replrule. Till exempel test_replrule. Om du vill skapa en ny brandväggsregel på servern kör du kommandot az postgres server firewall-rule create .

Med Azure Portal

  1. Ange stöd för Azure-replikering till logiskt. Välj Spara.

    Azure Database for PostgreSQL – Replikering – Stöd för Azure-replikering

  2. Starta om servern för att tillämpa ändringen genom att välja Ja.

    Azure Database for PostgreSQL – Replikering – Bekräfta omstart

  3. Om du kör Postgres 9.5 eller 9.6 och använder åtkomst till offentligt nätverk lägger du till brandväggsregeln för att inkludera klientens offentliga IP-adress där du ska köra den logiska replikeringen. Namnet på brandväggsregeln måste innehålla _replrule. Till exempel test_replrule. Välj sedan Spara.

    Azure Database for PostgreSQL – Replikering – Lägg till brandväggsregel

Starta logisk avkodning

Logisk avkodning kan användas via strömningsprotokoll eller SQL-gränssnitt. Båda metoderna använder replikeringsfack. Ett fack representerar en ström av ändringar från en enskild databas.

Att använda ett replikeringsfack kräver Postgres replikeringsprivilegier. För närvarande är replikeringsbehörigheten endast tillgänglig för serverns administratörsanvändare.

Direktuppspelningsprotokoll

Att använda ändringar med strömningsprotokollet är ofta att föredra. Du kan skapa en egen konsument/anslutningsapp eller använda ett verktyg som Debezium.

Besök wal2json-dokumentationen för ett exempel med hjälp av strömningsprotokollet med pg_recvlogical.

SQL-gränssnitt

I exemplet nedan använder vi 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. Förbruka ä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. Släpp facket när du är klar med det.

    SELECT pg_drop_replication_slot('test_slot');

Övervakningsfack

Du måste övervaka logisk avkodning. Alla oanvända replikeringsfack måste tas bort. Facken håller fast vid Postgres WAL-loggar och relevanta systemkataloger tills ändringar har lästs av en konsument. Om konsumenten misslyckas eller inte har konfigurerats korrekt kommer de obekräftade loggarna att staplas upp och fylla lagringen. Dessutom ökar obekräftade loggar risken för transaktions-ID-omslutning. Båda situationerna kan göra att servern blir otillgänglig. Därför är det viktigt att logiska replikeringsfack används kontinuerligt. Om ett logiskt replikeringsfack inte längre används släpper du det omedelbart.

Kolumnen "aktiv" i vyn pg_replication_slots anger om det finns en konsument som är ansluten till ett fack.

SELECT * FROM pg_replication_slots;

Ange aviseringar för lagring som används och Maximal fördröjning mellan repliker för att meddela dig när värdena ökar över normala tröskelvärden.

Viktigt!

Du måste släppa oanvända replikeringsfack. Om du inte gör det kan det leda till att servern inte är tillgänglig.

Så här släpper du ett fack

Om du inte aktivt använder ett replikeringsfack bör du släppa det.

Så här släpper du ett replikeringsfack med namnet test_slot med SQL:

SELECT pg_drop_replication_slot('test_slot');

Viktigt!

Om du slutar använda logisk avkodning ändrar du azure.replication_support tillbaka till replica eller off. WAL-informationen som behålls av logical är mer utförlig och bör inaktiveras när logisk avkodning inte används.

Nästa steg