sql >> Databasteknik >  >> RDS >> PostgreSQL

Uppgradering till PostgreSQL13

I en nyligen publicerad blogg om vad som är nytt i PostgreSQL 13 har vi granskat några av de nya funktionerna i den här versionen, men nu ska vi se hur man uppgraderar för att kunna dra nytta av alla dessa nämnda funktioner .

Uppgraderar till PostgreSQL 13

Om du vill uppgradera din nuvarande PostgreSQL-version till denna nya, har du tre huvudsakliga inbyggda alternativ för att utföra denna uppgift.

  • Pg_dump/pg_dumpall:Det är ett logiskt säkerhetskopieringsverktyg som låter dig dumpa din data och återställa den i ny PostgreSQL-version. Här kommer du att ha en stilleståndsperiod som kommer att variera beroende på din datastorlek. Du måste stoppa systemet eller undvika ny data i den primära noden, köra pg_dump, flytta den genererade dumpen till den nya databasnoden och återställa den. Under denna tid kan du inte skriva in i din primära PostgreSQL-databas för att undvika datainkonsekvens.

  • Pg_upgrade:Det är ett PostgreSQL-verktyg för att uppgradera din PostgreSQL-version på plats. Det kan vara farligt i en produktionsmiljö och vi rekommenderar inte den här metoden i så fall. Om du använder den här metoden kommer du också ha driftstopp, men förmodligen kommer det att vara betydligt mindre än med den tidigare pg_dump-metoden.

  • Logisk replikering:Sedan PostgreSQL 10 kan du använda denna replikeringsmetod som låter dig utföra större versionsuppgraderingar med noll (eller nästan noll) stilleståndstid. På detta sätt kan du lägga till en standby-nod i den senaste PostgreSQL-versionen, och när replikeringen är uppdaterad kan du utföra en failover-process för att främja den nya PostgreSQL-noden.

Så, låt oss se dessa metoder en efter en.

Använda pg_dump/pg_dumpall

Om driftstopp inte är ett problem för dig är den här metoden ett enkelt sätt att uppgradera.

För att skapa dumpen kan du köra:

$ pg_dumpall > dump_pg12.out

Eller för att skapa en dump av en enda databas:

$ pg_dump world > dump_world_pg12.out

Då kan du kopiera denna dump till servern med den nya PostgreSQL-versionen och återställa den:

$ psql -f dump_pg12.out postgres

Tänk på att du måste stoppa din ansökan eller undvika att skriva i din databas under denna process, annars kommer du att få datainkonsekvens eller en potentiell dataförlust.

Använda pg_upgrade

Först måste du ha både den nya och den gamla PostgreSQL-versionen installerad på servern.

$ rpm -qa |grep postgres
postgresql13-contrib-13.3-2PGDG.rhel8.x86_64
postgresql13-server-13.3-2PGDG.rhel8.x86_64
postgresql13-libs-13.3-2PGDG.rhel8.x86_64
postgresql13-13.3-2PGDG.rhel8.x86_64
postgresql12-libs-12.7-2PGDG.rhel8.x86_64
postgresql12-server-12.7-2PGDG.rhel8.x86_64
postgresql12-12.7-2PGDG.rhel8.x86_64
postgresql12-contrib-12.7-2PGDG.rhel8.x86_64

Då, först kan du köra pg_upgrade för att testa uppgraderingen genom att lägga till -c-flaggan:

$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data -c

Performing Consistency Checks on Old Live Server

------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible*

Flaggorna betyder:

  • -b:Den gamla körbara PostgreSQL-katalogen

  • -B:Den nya körbara PostgreSQL-katalogen

  • -d:Den gamla databasklusterkonfigurationskatalogen

  • -D:Den nya databasklusterkonfigurationskatalogen

  • -c:Kontrollera endast kluster. Det ändrar ingen data

Om allt ser bra ut kan du köra samma kommando utan flaggan -c och det kommer att uppgradera din PostgreSQL-server. För detta måste du först stoppa din nuvarande version och köra det nämnda kommandot.

$ systemctl stop postgresql-12
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data
...

Upgrade Complete

----------------

Optimizer statistics are not transferred by pg_upgrade so, once you start the new server, consider running:

    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:

    ./delete_old_cluster.sh

När den är klar, som meddelandet antyder, kan du använda dessa skript för att analysera den nya PostgreSQL-servern och ta bort den gamla när den är säker.

Använda logisk replikering

Logisk replikering är en metod för att replikera dataobjekt och deras ändringar, baserat på deras replikeringsidentitet. Den är baserad på ett publicerings- och prenumerationsläge, där en eller flera prenumeranter prenumererar på en eller flera publikationer på en förlagsnod.

Så baserat på detta, låt oss konfigurera utgivaren, i det här fallet PostgreSQL 12-servern, enligt följande.

Redigera postgresql.conf-konfigurationsfilen:

listen_addresses = '*'
wal_level = logical
max_wal_senders = 8
max_replication_slots = 4

Redigera pg_hba.conf-konfigurationsfilen:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host     all     rep1     10.10.10.141/32     md5

Använd abonnentens IP-adress där.

Nu måste du konfigurera abonnenten, i det här fallet PostgreSQL 13-servern, enligt följande.

Redigera postgresql.conf-konfigurationsfilen:

listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8

Eftersom denna PostgreSQL 13 kommer att bli den nya primära noden snart, bör du överväga att lägga till parametrarna wal_level och archive_mode i detta steg för att undvika en ny omstart av tjänsten senare.

wal_level = logical
archive_mode = on

Dessa parametrar kommer att vara användbara om du vill lägga till en ny replik eller för att använda PITR-säkerhetskopior.

Vissa av dessa ändringar kräver omstart av servern, så starta om både utgivare och prenumerant.

Nu, i utgivaren, måste du skapa användaren som ska användas av abonnenten för att komma åt den. Rollen som används för replikeringsanslutningen måste ha attributet REPLICATION och, för att kunna kopiera den initiala datan, behöver den även SELECT-behörigheten på den publicerade tabellen:

world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '********' REPLICATION;
CREATE ROLE
world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;
GRANT

Låt oss skapa publikationen pub1 i utgivarnoden, för alla tabeller:

world=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATION

Eftersom schemat inte är replikerat måste du ta en säkerhetskopia i din PostgreSQL 12 och återställa den i din PostgreSQL 13. Säkerhetskopieringen kommer endast att tas för schemat eftersom informationen kommer att replikeras i den initiala överföring.

I PostgreSQL 12, kör:

$ pg_dumpall -s > schema.sql

I PostgreSQL 13, kör:

$ psql -d postgres -f schema.sql

När du har ditt schema i PostgreSQL 13 måste du skapa prenumerationen och ersätta värdena för värd, dbname, användare och lösenord med de som motsvarar din miljö.

world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.140 dbname=world user=rep1 password=********' PUBLICATION pub1; 
NOTICE:  created replication slot "sub1" on publisher
CREATE SUBSCRIPTION

Ovanstående startar replikeringsprocessen, som synkroniserar det ursprungliga tabellinnehållet i tabellerna i publikationen och sedan börjar replikera inkrementella ändringar av dessa tabeller.

För att verifiera den skapade prenumerationen kan du använda katalogen pg_stat_subscription. Den här vyn kommer att innehålla en rad per prenumeration för huvudarbetaren (med null PID om arbetaren inte körs), och ytterligare rader för arbetare som hanterar den initiala datakopian av de prenumererade tabellerna.

world=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid                 | 16421
subname               | sub1
pid                   | 464
relid                 |
received_lsn          | 0/23A8490
last_msg_send_time    | 2021-07-23 22:42:26.358605+00
last_msg_receipt_time | 2021-07-23 22:42:26.358842+00
latest_end_lsn        | 0/23A8490
latest_end_time       | 2021-07-23 22:42:26.358605+00

För att verifiera när den initiala överföringen är klar kan du kontrollera variabeln srsubstate på pg_subscription_rel-katalogen. Den här katalogen innehåller tillståndet för varje replikerad relation i varje prenumeration.

world=# SELECT * FROM pg_subscription_rel;
 srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+-----------
   16421 |   16408 | r          | 0/23B1738
   16421 |   16411 | r          | 0/23B17A8
   16421 |   16405 | r          | 0/23B17E0
   16421 |   16402 | r          | 0/23B17E0
(4 rows)

Kolumnbeskrivningar:

  • srsubid:Referens till prenumeration.

  • srrelid:Referens till relation.

  • srsubstate:Tillståndskod:i =initialisera, d =data kopieras, s =synkroniseras, r =klar (normal replikering).

  • srsublsn:Avsluta LSN för s- och r-tillstånd.

När den första överföringen är klar har du allt redo för att peka din applikation till din nya PostgreSQL 13-server.

Slutsats

Som du kan se har PostgreSQL olika alternativ att uppgradera, beroende på dina krav och stilleståndstolerans.

Oavsett vilken typ av teknik du använder är det en nödvändig men svår uppgift att hålla dina databasservrar uppdaterade genom att utföra regelbundna uppgraderingar, eftersom du måste se till att du inte förlorar data eller datainkonsekvens efter uppgradering. En detaljerad och beprövad plan är nyckeln här, och naturligtvis måste den innehålla ett återställningsalternativ, för säkerhets skull.


  1. Hur man skapar en vy i SQL Server

  2. Bygg snabbt ett PHP CRUD-gränssnitt med PDO Advanced CRUD Generator Tool

  3. Oracle till PostgreSQL — Markörer och lträd

  4. PostgreSQL LIKE-frågeprestandavariationer