Överväganden vid användning av tillägg och moduler i Azure Database for PostgreSQL flexibel server

Den här artikeln beskriver särskilda överväganden för att använda vissa tillägg eller moduler i Azure Database for PostgreSQL flexibel server.

Allmänna överväganden för tillägg

Om du vill använda ett tillägg i Azure Database for PostgreSQL flexibel server måste du:

  • Tillåt tillägg. Om du inte tillåter tillägget kan alla försök att köra CREATE EXTENSION, ALTER EXTENSION, DROP EXTENSIONeller COMMENT ON EXTENSION misslyckas med ett fel som anger att det refererade tillägget inte är tillåtet.
  • Om tillägget distribuerar ett delat binärt bibliotek som kräver allokering och åtkomst till delat minne och måste läsas in när servern startar följer du anvisningarna i belastningsbiblioteken.
  • Skapa tillägget i de databaser där du vill att tillägget ska distribuera SQL-objekten som distribueras med tillägget.
  • Släpp tillägget. När du vill ta bort alla SQL-objekt som distribueras av tillägget från databasen.
  • Uppdatera tillägg för att uppdatera till den senaste versionen av alla SQL-artefakter som distribuerats av ett tillägg som redan är installerat.
  • Visa installerade tillägg och deras motsvarande versioner.

Om du får ett fel när du kör kommandona CREATE EXTENSION, ALTER EXTENSION, DROP EXTENSIONeller COMMENT ON EXTENSION på din Azure Database for PostgreSQL flexibla server kan du läsa listan över möjliga fel och vad som kan vara orsaken till varje fel.

Allmänna överväganden för moduler

Om du vill använda en modul i Azure Database for PostgreSQL – Flexibel server lägger du till den i parametern shared_preload_libraries, enligt beskrivningen i läsa in bibliotek.

Moduler behöver inte vara på godkända listan. Det är ett exklusivt krav för tillägg.

Tillägg med specifika överväganden

I följande lista räknas alla tillägg som stöds upp som kräver specifika överväganden när de används i Azure Database for PostgreSQL flexibel server:

  • AGE
  • dblink
  • pg_buffercache
  • pg_cron
  • pg_hint_plan
  • pg_repack
  • pg_stat_statements
  • pgcrypto
  • postgres_fdw
  • pgstattuple
  • timescaledb

AGE

Apache AGE-tillägget är ett graftillägg för PostgreSQL som stöds av Azure Database for PostgreSQL. Den innehåller funktioner för grafdatabaser, stöd för öppna cypher-frågor och möjligheten att köra komplexa frågor på grafdata som lagras i PostgreSQL. Apache AGE är ett projekt med öppen källkod som lanseras under Apache License 2.0.

Installera AGE

Om du vill använda AGE kontrollerar du att du tillåterlistning av tillägget, läser in dess bibliotek och installerar tillägget i databasen där du planerar att använda dess funktioner.

Med dblink tillägget kan du ansluta från en Azure Database for PostgreSQL flexibel server till en annan eller en annan databas på samma server. Azure Database for PostgreSQL stöder både inkommande och utgående anslutningar till valfri PostgreSQL-server. Den sändande servern måste tillåta utgående anslutningar till den mottagande servern. På samma sätt måste den mottagande servern tillåta anslutningar från den sändande servern.

Om du planerar att använda det här tillägget ska du distribuera dina servrar med integrering med virtuella nätverk. Som standard tillåter integrering av virtuella nätverk anslutningar mellan servrar i det virtuella nätverket. Du kan också välja att använda nätverkssäkerhetsgrupper för att anpassa åtkomsten.

pg_buffercache

pg_buffercache Använd tillägget för att undersöka innehållet i shared_buffers. Med det här tillägget kan du avgöra om en specifik relation cachelagras i shared_buffers. Det här tillägget kan hjälpa dig att felsöka problem med cachelagringsrelaterade prestanda.

Det här tillägget är en del av kärninstallationen av PostgreSQL och det är enkelt att installera.

CREATE EXTENSION pg_buffercache;

pg_cron

Tillägget pg_cron är en enkel, cron-baserad jobbschemaläggare för PostgreSQL som körs i databasen som ett tillägg. Tillägget pg_cron kan köra schemalagda underhållsaktiviteter i en PostgreSQL-databas. Du kan till exempel köra ett periodiskt vakuum av en tabell eller ta bort gamla datajobb.

Tillägget pg_cron kan köra flera jobb parallellt, men det körs högst en instans av ett jobb i taget. Om en andra körning ska starta innan den första slutförs placeras den andra körningen i kö och startas så snart den första körningen är klar. På ett sådant sätt säkerställer det att jobb körs precis så många gånger som de är schemalagda och inte körs samtidigt med varandra.

Kontrollera att värdet som shared_preload_libraries har angetts innehåller pg_cron. Det här tillägget stöder inte inläsningen av biblioteket som ett resultat av att köra CREATE EXTENSION. Alla försök att köra CREATE EXTENSION under förutsättning att tillägget inte lades till shared_preload_libraries, eller om servern inte startades om efter att det lades till, resulterar i ett fel där texten säger pg_cron can only be loaded via shared_preload_libraries, och vars ledtråd är Add pg_cron to the shared_preload_libraries configuration variable in postgresql.conf.

Om du vill använda pg_cronkontrollerar du att du läser in dess delade bibliotek vid serverstart, att det är tillåtetlistat och att det är installerat i alla databaser som du vill interagera med dess funktioner från, med hjälp av de SQL-artefakter som skapas.

Examples

  1. Ta bort gamla data på lördag klockan 03:30 (GMT).

    SELECT cron.schedule('30 3 * * 6', $$DELETE FROM events WHERE event_time < now() - interval '1 week'$$);
    
  2. Så här kör du vakuumet varje dag klockan 10:00 (GMT) i standarddatabasen postgres.

    SELECT cron.schedule('0 10 * * *', 'VACUUM');
    
  3. Så här avbokar du alla aktiviteter från pg_cron.

    SELECT cron.unschedule(jobid) FROM cron.job;
    
  4. Om du vill se alla jobb som för närvarande är schemalagda med pg_cron.

    SELECT * FROM cron.job;
    
  5. För att köra vakuumet varje dag klockan 10:00 (GMT) i testcron databasen.

    SELECT cron.schedule_in_database('VACUUM','0 10 * * *', 'VACUUM', 'testcron', null, TRUE);
    

Fler exempel

Från och med pg_cron version 1.4 kan du använda cron.schedule_in_database funktionerna och cron.alter_job för att schemalägga jobbet i en specifik databas och uppdatera ett befintligt schema.

Funktionen cron_schedule_in_database tillåter användarnamnet som en valfri parameter. Att ange användarnamnet till ett värde som inte är null kräver PostgreSQL-superanvändarbehörighet och stöds inte i Azure Database for PostgreSQL flexibel server. Föregående exempel visar körning av den här funktionen med en valfri användarnamnsparameter utelämnad eller inställd på null, som kör jobbet i kontexten för användaren som schemalägger jobbet, som ska ha azure_pg_admin rollbehörigheter.

  1. Ta bort gamla data på lördag klockan 03:30 (GMT) på databasen DBName.

    SELECT cron.schedule_in_database('JobName', '30 3 * * 6', $$DELETE FROM events WHERE event_time < now() - interval '1 week'$$,'DBName');
    
  2. För att uppdatera eller ändra databasnamnet för det befintliga schemat

    SELECT cron.alter_job(job_id:=MyJobID,database:='NewDBName');
    

pg_hint_plan

Med pg_hint_plan tillägget kan du justera PostgreSQL-körningsplaner med hjälp av "tips" i SQL-kommentarer, till exempel:

/*+ SeqScan(a) */

Tillägget pg_hint_plan läser hintningsfraser i en kommentar i ett särskilt format som ges med mål-SQL-satsen. Det specifika formuläret börjar med teckensekvensen /*+ och slutar med */. Tipsfraser består av tipsnamn och följande parametrar som omges av parenteser och avgränsas av blanksteg. Nya rader för läsbarhet kan avgränsa varje tipsfras.

Example:

/*+
 HashJoin(a b)
 SeqScan(a)
 */
    SELECT *
    FROM pgbench_branches b
    JOIN pgbench_accounts a ON b.bid = a.bid
    ORDER BY a.aid;

Föregående exempel gör att planeraren använder resultatet av en seqscan i tabellen a för att kombinera med tabellen b som en hashjoin.

För att använda tillägget pg_hint_plan, se till att du tillåtslistar tillägget, läser in dess bibliotek och installerar tillägget i databasen där du planerar att använda dess funktionalitet.

pg_repack

Förstagångsanvändare av pg_repack tillägget ställer vanligtvis följande fråga: Är pg_repack ett tillägg eller en körbar fil på klientsidan som psql eller pg_dump?

pg_repack är faktiskt både och. pg_repack/lib har koden för tillägget, inklusive schemat och SQL-artefakterna som skapas, och C-biblioteket som implementerar koden för flera av dessa funktioner.

Å andra sidan har pg_repack/bin koden för klientprogrammet, som kan interagera med programmerbarhetselementen som implementeras i tillägget. Det här klientprogrammet syftar till att underlätta komplexiteten i att interagera med de olika gränssnitten som visas av tillägget på serversidan. Det ger användaren vissa kommandoradsalternativ som är lättare att förstå. Klientprogrammet är värdelöst utan tillägget som skapats i databasen som det pekar på. Tillägget på serversidan är helt funktionellt, men det kräver att användaren förstår ett komplicerat interaktionsmönster. Det mönstret består av att köra frågor för att hämta data som används som indata till funktioner som implementeras av tillägget och så vidare.

Behörighet nekad för schemaompaketering

Eftersom tillägget ger behörighet till ompaketeringsschemat kan du för närvarande bara köra pg_repack-funktionalitet i kontexten för azure_pg_admin.

Du kanske lägger märke till att om ägaren till en tabell, som inte är azure_pg_admin, försöker köra pg_repack, får de följande fel:

NOTICE: Setting up workers.conns
ERROR: pg_repack failed with error: ERROR:  permission denied for schema repack
LINE 1: select repack.version(), repack.version_sql()

För att undvika det felet kör du pg_repack från kontexten för azure_pg_admin.

pg_stat_statements

Tillägget pg_stat_statements ger dig en vy över alla frågor som körs i databasen. Den här informationen är användbar för att förstå frågearbetsbelastningens prestanda i ett produktionssystem.

Tillägget pg_stat_statements förinläses i shared_preload_libraries på varje Azure Database for PostgreSQL – Flexibel server för att göra det möjligt att spåra statistik över körning av SQL-instruktioner.

Av säkerhetsskäl måste du tillåta tillägget pg_stat_statements och installera det med kommandot CREATE EXTENSION.

Inställningen pg_stat_statements.track, som styr vilka instruktioner tillägget spårar, är standardvärdet , vilket innebär att topalla instruktioner som utfärdas direkt av klienter spåras. De två andra spårningsnivåerna är none och all. Du kan konfigurera den här inställningen som en parameter.

Det finns en kompromiss mellan frågekörningsinformationen som pg_stat_statements tillägget tillhandahåller och serverprestanda, eftersom det loggar varje SQL-instruktion. Om du inte aktivt använder pg_stat_statements tillägget anger du pg_stat_statements.track till none. Vissa övervakningstjänster från tredje part kan förlita sig på pg_stat_statements för att leverera insikter om frågeprestanda, så bekräfta om det är fallet för dig.

pgcrypto

Azure Database for PostgreSQL stöder kryptering på programnivå på kolumnnivå via pgcrypto PostgreSQL-tillägget. Med pgcrypto-tillägget kan program uttryckligen anropa kryptografiska funktioner i PostgreSQL SQL-instruktioner för att kryptera eller hash-kolumnvärden med hjälp av kryptografiska algoritmer som tillhandahålls av det underliggande OpenSSL-biblioteket.

Från och med Azure Linux 3.0 använder operativsystemet OpenSSL 3.0, som flyttar flera äldre och svagare kryptografiska algoritmer och lågnivå-API:er till en separat äldre provider som inte läses in som standard. Den här ändringen främjar användningen av moderna, säkrare kryptografiska algoritmer och OpenSSL:s övergripande EVP-API:er (Envelope).

Därför är kryptografiska algoritmer som OpenSSL 3.0 klassificerar som äldre inte tillgängliga som standard för användning av pgcrypto på Azure Database for PostgreSQL servrar som kör Azure Linux 3.0.

Inaktuella kryptografiska algoritmer

Följande äldre kryptografiska algoritmer finns i den äldre OpenSSL 3.0-providern och är inte tillgängliga som standard på Azure Database for PostgreSQL servrar som kör Azure Linux 3.0. Tidigare plattformsversioner kan ha gjort det möjligt för pgcrypto att använda dessa algoritmer, men Azure Linux 3.0 stöder dem inte längre.

Symmetriska krypteringsalgoritmer (chiffer):

  • Blåsfisk (BF-CBC)
  • CAST
  • DES (enkel DES, inte 3DES)
  • IDÉ
  • RC2
  • RC4
  • RC5
  • FRÖ

Algoritmer för meddelandesammandrag och hash:

  • MD2
  • MD4
  • MDC2
  • RIPEMD-160
  • SHA-1 (inaktuell för digitala signaturer men kan fortfarande tillåtas för specifika HMAC-scenarier beroende på konfiguration)
  • Whirlpool

Azure Database for PostgreSQL uppgraderingar till Azure Linux 3.0 ingår i pågående plattformsförbättringar. Program som förlitar sig på pgcrypto bör se till att de använder moderna kryptografiska algoritmer som stöds när de utför kryptering på programnivå på kolumnnivå.

postgres_fdw

Med postgres_fdw tillägget kan du ansluta från en Azure Database for PostgreSQL flexibel server till en annan server eller till en annan databas på samma server. Azure Database for PostgreSQL stöder både inkommande och utgående anslutningar till valfri PostgreSQL-server. Den sändande servern måste tillåta utgående anslutningar till den mottagande servern. På samma sätt måste den mottagande servern tillåta anslutningar från den sändande servern.

Om du planerar att använda det här tillägget ska du distribuera dina servrar med integrering med virtuella nätverk. Som standard tillåter integrering av virtuella nätverk anslutningar mellan servrar i det virtuella nätverket. Du kan också välja att använda nätverkssäkerhetsgrupper för att anpassa åtkomsten.

pgstattuple

När du använder pgstattuple tillägget för att försöka hämta tuppelns statistik från objekt som lagras i pg_toast schemat i PostgreSQL-versionerna 11 till 13 får du felet "behörighet nekad för schema pg_toast".

Behörighet nekad för schema pg_toast

Kunder som använder PostgreSQL version 11 till och med 13 på Azure Database for PostgreSQL flexibel server kan inte använda pgstattuple tillägget på objekt i pg_toast schemat.

I PostgreSQL 16 och 17 ges rollen pg_read_all_data automatiskt till azure_pg_admin, vilket gör att pgstattuple fungerar korrekt. I PostgreSQL 14 och 15 kan kunderna manuellt tilldela rollen pg_read_all_data till azure_pg_admin för att uppnå samma resultat. Men i PostgreSQL 11 till 13 pg_read_all_data finns inte rollen.

Kunder kan inte bevilja nödvändiga behörigheter direkt. Om du behöver köra pgstattuple för att komma åt objekt under pg_toast schemat skapar du en Azure support begäran.

timescaledb

Tillägget timescaledb är en tidsseriedatabas som paketeras som ett tillägg för PostgreSQL. Den tillhandahåller tidsorienterade analysfunktioner och optimeringar och skalar PostgreSQL för tidsseriearbetsbelastningar.

Läs mer om TimescaleDB, ett registrerat varumärke som tillhör Timescale, Inc. Azure Database for PostgreSQL tillhandahåller TimescaleDB Apache-2-utgåvan.

Installera TimescaleDB

För att använda timescaledb, kontrollerar du att du tillåter lista av tillägget, läser in dess bibliotek och installerar tillägget i databasen där du planerar att använda dess funktionalitet.

Nu kan du skapa en TimescaleDB-hypertabell från grunden eller migrera befintliga tidsseriedata i PostgreSQL.

Mer information om hur du återställer en tidsskala-databas med hjälp av pg_dump och pg_restorefinns i Dokumentation om tidsskala.

Återställ en TimescaleDB-databas med hjälp av timescaledb-backup

När du kör proceduren SELECT timescaledb_post_restore() kan du få behörigheter som nekas när du timescaledb.restoring uppdaterar flaggan. Det här felet inträffar på grund av den begränsade ALTER DATABASE behörigheten i PaaS-molndatabastjänster. I det här fallet kan du utföra en alternativ metod med hjälp av timescaledb-backup verktyget för att säkerhetskopiera och återställa databasen Tidsskala. Timescaledb-backup är ett program som gör dumpning och återställning av en TimescaleDB-databas enklare, mindre felbenägen och mer högpresterande.

Följ stegen nedan:

  1. Installera verktygen enligt beskrivningen i Installera timescaledb-backup.

  2. Skapa en målserver och en databas i Azure Database for PostgreSQL – Flexibel server.

  3. Aktivera tidsskaletillägg.

  4. azure_pg_admin Bevilja rollen till den användare som används av ts-restore.

  5. Kör ts-restore för att återställa databasen.

Mer information om dessa verktyg finns i timescaledb-backup.

Tillägg och högre versionsuppgradering

Azure Database for PostgreSQL erbjuder en huvudversionsuppgraderingsfunktion på plats som utför en uppgradering på plats av den Azure Database for PostgreSQL flexibla servern, med bara en enkel interaktion från användaren. Huvudversionsuppgradering på plats förenklar uppgraderingsprocessen för Azure Database for PostgreSQL, vilket minimerar störningarna för användare och program som kommer åt servern. Huvudversionsuppgraderingar på plats stöder inte specifika tillägg, och det finns vissa begränsningar för att uppgradera vissa tillägg.

Tilläggen anon, Apache AGE, dblink, orafce, postgres_fdwoch timescaledb stöds inte för alla Azure Database for PostgreSQL flexibla serverversioner när du använder huvudversionsuppdateringsfunktionen på plats.

Moduler med specifika överväganden

I följande lista räknas alla moduler som stöds upp som kräver specifika överväganden när de används i en Azure Database for PostgreSQL flexibel server:

  • pg_failover_slots

pg_failover_slots

Modulen pg_failover_slots förbättrar Azure Database for PostgreSQL när du arbetar med både logisk replikering och servrar med hög tillgänglighet. Den hanterar effektivt utmaningen i PostgreSQL-standardmotorn som inte bevarar logiska replikeringsplatser efter en redundansväxling. Att underhålla dessa platser är viktigt för att förhindra replikeringspauser eller datamatchningar under ändringar av primär serverrollen, vilket säkerställer driftkontinuitet och dataintegritet.

Tillägget effektiviserar redundansväxlingen genom att hantera nödvändig överföring, rensning och synkronisering av replikeringsplatser, vilket ger en sömlös övergång under ändringar i serverrollen.

Du hittar mer information och instruktioner om hur du använder modulen pg_failover_slotsgithub-sidan.

Om du vill använda modulen pg_failover_slots kontrollerar du att dess bibliotek läses in när servern startar.