Opgradering til PostgreSQL13

I en nylig blog om, hvad der er nyt i PostgreSQL 13, gennemgik vi nogle af de nye funktioner i denne version, men lad os nu se, hvordan man opgraderer for at kunne drage fordel af alle disse nævnte funktioner .

Opgradering til PostgreSQL 13

Hvis du vil opgradere din nuværende PostgreSQL-version til denne nye, har du tre hovedindbyggede muligheder for at udføre denne opgave.

Pg_dump/pg_dumpall:Det er et logisk backupværktøj, der giver dig mulighed for at dumpe dine data og gendanne dem i ny PostgreSQL-version. Her vil du have en nedetidsperiode, der vil variere i henhold til din datastørrelse. Du skal stoppe systemet eller undgå nye data i den primære node, køre pg_dump, flytte det genererede dump til den nye databasenode og gendanne det. I dette tidsrum kan du ikke skrive ind i din primære PostgreSQL-database for at undgå datainkonsistens.
Pg_upgrade:Det er et PostgreSQL-værktøj til at opgradere din PostgreSQL-version på stedet. Det kan være farligt i et produktionsmiljø, og vi anbefaler ikke denne metode i så fald. Ved at bruge denne metode vil du også have nedetid, men sandsynligvis vil det være betydeligt mindre end ved at bruge den tidligere pg_dump-metode.
Logisk replikering:Siden PostgreSQL 10 kan du bruge denne replikeringsmetode, som giver dig mulighed for at udføre større versionsopgraderinger med nul (eller næsten nul) nedetid. På denne måde kan du tilføje en standby-node i den sidste PostgreSQL-version, og når replikeringen er opdateret, kan du udføre en failover-proces for at fremme den nye PostgreSQL-node.

Så lad os se disse metoder én efter én.

Brug af pg_dump/pg_dumpall

Hvis nedetid ikke er et problem for dig, er denne metode en nem måde at opgradere.

For at oprette dumpet kan du køre:

$ pg_dumpall > dump_pg12.out

Eller for at oprette et dump af en enkelt database:

$ pg_dump world > dump_world_pg12.out

Derefter kan du kopiere dette dump til serveren med den nye PostgreSQL-version og gendanne den:

$ psql -f dump_pg12.out postgres

Husk, at du bliver nødt til at stoppe din ansøgning eller undgå at skrive i din database under denne proces, ellers vil du have datainkonsekvens eller et potentielt datatab.

Brug af pg_upgrade

For det første skal du have både den nye og den gamle PostgreSQL-version installeret på serveren.

$ 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

Derefter kan du først køre pg_upgrade for at teste opgraderingen ved at tilføje -c-flaget:

$ /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*

Flagene betyder:

-b:Den gamle PostgreSQL eksekverbare mappe
-B:Den nye PostgreSQL eksekverbare mappe
-d:Den gamle databaseklyngekonfigurationsmappe
-D:Den nye databaseklyngekonfigurationsmappe
-c:Tjek kun klynger. Det ændrer ingen data

Hvis alt ser fint ud, kan du køre den samme kommando uden flaget -c, og det vil opgradere din PostgreSQL-server. Til dette skal du først stoppe din nuværende version og køre den nævnte kommando.

$ 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 er fuldført, som meddelelsen antyder, kan du bruge disse scripts til at analysere den nye PostgreSQL-server og slette den gamle, når den er sikker.

Brug af logisk replikering

Logisk replikering er en metode til at replikere dataobjekter og deres ændringer baseret på deres replikeringsidentitet. Den er baseret på en udgivelses- og abonnenttilstand, hvor en eller flere abonnenter abonnerer på en eller flere publikationer på en udgivernode.

Så baseret på dette, lad os konfigurere udgiveren, i dette tilfælde PostgreSQL 12-serveren, som følger.

Rediger postgresql.conf-konfigurationsfilen:

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

Rediger pg_hba.conf-konfigurationsfilen:

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

Brug abonnentens IP-adresse der.

Nu skal du konfigurere abonnenten, i dette tilfælde PostgreSQL 13-serveren, som følger.

Rediger postgresql.conf-konfigurationsfilen:

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

Da denne PostgreSQL 13 snart bliver den nye primære node, bør du overveje at tilføje parametrene wal_level og archive_mode i dette trin for at undgå en ny genstart af tjenesten senere.

wal_level = logical
archive_mode = on

Disse parametre vil være nyttige, hvis du vil tilføje en ny replika eller til at bruge PITR-sikkerhedskopier.

Nogle af disse ændringer kræver en servergenstart, så genstart både udgiver og abonnent.

Nu skal du i udgiveren oprette den bruger, der skal bruges af abonnenten for at få adgang til den. Rollen, der bruges til replikeringsforbindelsen, skal have attributten REPLICATION, og for at kunne kopiere de oprindelige data, skal den også have SELECT-privilegiet på den offentliggjorte tabel:

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

Lad os oprette publikationen pub1 i udgivernoden for alle tabellerne:

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

Da skemaet ikke er replikeret, skal du tage en sikkerhedskopi i din PostgreSQL 12 og gendanne den i din PostgreSQL 13. Sikkerhedskopien vil kun blive taget for skemaet, da informationen vil blive replikeret i den indledende overførsel.

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 dit skema i PostgreSQL 13, skal du oprette abonnementet og erstatte værdierne for vært, dbname, bruger og adgangskode med dem, der svarer til dit 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

Ovenstående starter replikeringsprocessen, som synkroniserer det indledende tabelindhold i tabellerne i publikationen og derefter begynder at replikere trinvise ændringer af disse tabeller.

For at bekræfte det oprettede abonnement kan du bruge pg_stat_subscription-kataloget. Denne visning vil indeholde én række pr. abonnement for hovedarbejderen (med null PID, hvis arbejderen ikke kører), og yderligere rækker for arbejdere, der håndterer den indledende datakopi af de tilmeldte tabeller.

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

For at kontrollere, hvornår den indledende overførsel er afsluttet, kan du tjekke srsubstate-variablen på pg_subscription_rel-kataloget. Dette katalog indeholder tilstanden for hver replikeret relation i hvert abonnement.

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)

Kolonnebeskrivelser:

srsubid:Reference til abonnement.
srrelid:Reference til relation.
srsubstate:Tilstandskode:i =initialisere, d =data bliver kopieret, s =synkroniseret, r =klar (normal replikering).
srsublsn:Afslut LSN for s- og r-tilstande.

Når den indledende overførsel er færdig, har du alt klar til at pege din applikation til din nye PostgreSQL 13-server.

Konklusion

Som du kan se, har PostgreSQL forskellige muligheder for at opgradere, afhængigt af dine krav og nedetidstolerance.

Uanset hvilken slags teknologi du bruger, er det en nødvendig, men vanskelig opgave at holde dine databaseservere opdaterede ved at udføre regelmæssige opgraderinger, da du skal sikre dig, at du ikke mister data eller datainkonsistens efter opgradering. En detaljeret og testet plan er nøglen her, og den skal selvfølgelig indeholde en tilbagerulningsmulighed, for en sikkerheds skyld.