Upgraden naar PostgreSQL13

In een recente blog over wat er nieuw is in PostgreSQL 13, hebben we enkele van de nieuwe functies van deze versie besproken, maar laten we nu eens kijken hoe we kunnen upgraden om te kunnen profiteren van al deze genoemde functionaliteiten .

Upgraden naar PostgreSQL 13

Als je je huidige PostgreSQL-versie wilt upgraden naar deze nieuwe, heb je drie hoofdeigen opties om deze taak uit te voeren.

Pg_dump/pg_dumpall:het is een logische back-uptool waarmee u uw gegevens kunt dumpen en terugzetten in de nieuwe PostgreSQL-versie. Hier heeft u een periode van uitval die zal variëren afhankelijk van uw gegevensomvang. U moet het systeem stoppen of nieuwe gegevens in het primaire knooppunt vermijden, de pg_dump uitvoeren, de gegenereerde dump naar het nieuwe databaseknooppunt verplaatsen en deze herstellen. Gedurende deze tijd kunt u niet in uw primaire PostgreSQL-database schrijven om inconsistentie van gegevens te voorkomen.
Pg_upgrade:het is een PostgreSQL-tool om je PostgreSQL-versie ter plekke te upgraden. In een productieomgeving kan het gevaarlijk zijn en in dat geval raden we deze methode niet aan. Als je deze methode gebruikt, heb je ook downtime, maar waarschijnlijk zal dit aanzienlijk minder zijn dan met de vorige pg_dump-methode.
Logische replicatie:sinds PostgreSQL 10 kunt u deze replicatiemethode gebruiken waarmee u belangrijke versie-upgrades kunt uitvoeren met nul (of bijna nul) uitvaltijd. Op deze manier kunt u een standby-knooppunt toevoegen in de laatste PostgreSQL-versie, en wanneer de replicatie up-to-date is, kunt u een failoverproces uitvoeren om het nieuwe PostgreSQL-knooppunt te promoten.

Dus laten we deze methoden een voor een bekijken.

Pg_dump/pg_dumpall gebruiken

Als downtime geen probleem voor je is, is deze methode een gemakkelijke manier om te upgraden.

Om de dump te maken, kun je het volgende uitvoeren:

$ pg_dumpall > dump_pg12.out

Of om een dump van een enkele database te maken:

$ pg_dump world > dump_world_pg12.out

Vervolgens kunt u deze dump naar de server kopiëren met de nieuwe PostgreSQL-versie en deze herstellen:

$ psql -f dump_pg12.out postgres

Houd er rekening mee dat u tijdens dit proces uw toepassing moet stoppen of schrijven in uw database moet vermijden, anders krijgt u gegevensinconsistentie of mogelijk gegevensverlies.

Pg_upgrade gebruiken

Eerst moet u zowel de nieuwe als de oude PostgreSQL-versie op de server hebben geïnstalleerd.

$ 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

Vervolgens kunt u eerst pg_upgrade uitvoeren om de upgrade te testen door de vlag -c toe te voegen:

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

De vlaggen betekenen:

-b:De oude uitvoerbare map van PostgreSQL
-B:de nieuwe uitvoerbare map van PostgreSQL
-d:De oude databaseclusterconfiguratiemap
-D:De nieuwe databaseclusterconfiguratiemap
-c:Controleer alleen clusters. Het verandert geen gegevens

Als alles er goed uitziet, kun je hetzelfde commando uitvoeren zonder de vlag -c en het zal je PostgreSQL-server upgraden. Hiervoor moet u eerst uw huidige versie stoppen en het genoemde commando uitvoeren.

$ 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

Als het klaar is, zoals het bericht suggereert, kun je die scripts gebruiken om de nieuwe PostgreSQL-server te analyseren en de oude te verwijderen als het veilig is.

Logische replicatie gebruiken

Logische replicatie is een methode voor het repliceren van gegevensobjecten en hun wijzigingen op basis van hun replicatie-identiteit. Het is gebaseerd op een publicatie- en abonnementsmodus, waarbij een of meer abonnees zich abonneren op een of meer publicaties op een uitgeversknooppunt.

Laten we op basis hiervan de uitgever, in dit geval de PostgreSQL 12-server, als volgt configureren.

Bewerk het postgresql.conf configuratiebestand:

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

Bewerk het pg_hba.conf configuratiebestand:

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

Gebruik daar het IP-adres van de abonnee.

Nu moet u de abonnee, in dit geval de PostgreSQL 13-server, als volgt configureren.

Bewerk het postgresql.conf configuratiebestand:

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

Aangezien deze PostgreSQL 13 binnenkort het nieuwe primaire knooppunt zal zijn, kunt u overwegen de parameters wal_level en archive_mode in deze stap toe te voegen, om te voorkomen dat de service later opnieuw wordt opgestart.

wal_level = logical
archive_mode = on

Deze parameters zijn handig als u een nieuwe replica wilt toevoegen of als u PITR-back-ups wilt gebruiken.

Sommige van deze wijzigingen vereisen een herstart van de server, dus herstart zowel de uitgever als de abonnee.

Nu moet u in de uitgever de gebruiker maken die door de abonnee moet worden gebruikt om toegang te krijgen. De rol die wordt gebruikt voor de replicatieverbinding moet het REPLICATION-attribuut hebben en om de initiële gegevens te kunnen kopiëren, heeft het ook het SELECT-privilege op de gepubliceerde tabel nodig:

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

Laten we de pub1-publicatie maken in het uitgeversknooppunt, voor alle tabellen:

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

Omdat het schema niet wordt gerepliceerd, moet u een back-up maken in uw PostgreSQL 12 en deze herstellen in uw PostgreSQL 13. De back-up wordt alleen gemaakt voor het schema, aangezien de informatie in de eerste overzetten.

Voer in PostgreSQL 12 uit:

$ pg_dumpall -s > schema.sql

Voer in PostgreSQL 13 uit:

$ psql -d postgres -f schema.sql

Zodra u uw schema in PostgreSQL 13 heeft, moet u het abonnement maken en de waarden host, dbname, gebruiker en wachtwoord vervangen door de waarden die overeenkomen met uw omgeving.

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

Het bovenstaande start het replicatieproces, dat de initiële tabelinhoud van de tabellen in de publicatie synchroniseert en vervolgens begint met het repliceren van incrementele wijzigingen in die tabellen.

Om het aangemaakte abonnement te verifiëren, kun je de pg_stat_subscription-catalogus gebruiken. Deze weergave bevat één rij per abonnement voor de hoofdwerker (met null-PID als de werknemer niet actief is) en extra rijen voor werknemers die de eerste gegevenskopie van de geabonneerde tabellen verwerken.

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

Om te controleren wanneer de eerste overdracht is voltooid, kun je de srsubstate-variabele in de pg_subscription_rel-catalogus controleren. Deze catalogus bevat de status voor elke gerepliceerde relatie in elk 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)

Kolombeschrijvingen:

srubid:verwijzing naar abonnement.
srrelid:verwijzing naar relatie.
srsubstate:Statuscode:i =initialiseren, d =gegevens worden gekopieerd, s =gesynchroniseerd, r =klaar (normale replicatie).
srsublsn:LSN beëindigen voor s- en r-statussen.

Als de eerste overdracht is voltooid, hebt u alles klaar om uw toepassing naar uw nieuwe PostgreSQL 13-server te verwijzen.

Conclusie

Zoals je kunt zien, heeft PostgreSQL verschillende opties om te upgraden, afhankelijk van je vereisten en downtimetolerantie.

Het maakt niet uit wat voor soort technologie u gebruikt, het up-to-date houden van uw databaseservers door regelmatige upgrades uit te voeren is een noodzakelijke maar moeilijke taak, aangezien u ervoor moet zorgen dat u geen gegevensverlies heeft of inconsistentie van gegevens na het upgraden. Een gedetailleerd en getest plan is hier de sleutel, en natuurlijk moet het een terugdraaioptie bevatten, voor het geval dat.