Aggiornamento a PostgreSQL13

In un recente blog sulle novità di PostgreSQL 13, abbiamo esaminato alcune delle nuove funzionalità di questa versione, ma ora vediamo come eseguire l'aggiornamento per poter sfruttare tutte queste funzionalità menzionate .

Aggiornamento a PostgreSQL 13

Se desideri aggiornare la tua versione corrente di PostgreSQL a questa nuova, hai tre opzioni native principali per eseguire questa attività.

Pg_dump/pg_dumpall:è uno strumento di backup logico che ti consente di scaricare i tuoi dati e ripristinarli nel nuova versione di PostgreSQL. Qui avrai un periodo di inattività che varierà in base alla dimensione dei tuoi dati. È necessario arrestare il sistema o evitare nuovi dati nel nodo primario, eseguire pg_dump, spostare il dump generato nel nuovo nodo del database e ripristinarlo. Durante questo periodo, non puoi scrivere nel tuo database PostgreSQL principale per evitare l'incoerenza dei dati.
Pg_upgrade:è uno strumento PostgreSQL per aggiornare la tua versione di PostgreSQL sul posto. Potrebbe essere pericoloso in un ambiente di produzione e in tal caso non consigliamo questo metodo. Usando questo metodo avrai anche tempi di inattività, ma probabilmente saranno notevolmente inferiori rispetto all'utilizzo del precedente metodo pg_dump.
Replica logica:da PostgreSQL 10, puoi utilizzare questo metodo di replica che ti consente di eseguire aggiornamenti di versione principali con zero (o quasi zero) tempi di inattività. In questo modo, puoi aggiungere un nodo standby nell'ultima versione di PostgreSQL e, quando la replica è aggiornata, puoi eseguire un processo di failover per promuovere il nuovo nodo PostgreSQL.

Quindi, vediamo questi metodi uno per uno.

Utilizzo di pg_dump/pg_dumpall

Nel caso in cui i tempi di inattività non siano un problema per te, questo metodo è un modo semplice per eseguire l'aggiornamento.

Per creare il dump, puoi eseguire:

$ pg_dumpall > dump_pg12.out

Oppure per creare un dump di un singolo database:

$ pg_dump world > dump_world_pg12.out

Quindi, puoi copiare questo dump sul server con la nuova versione di PostgreSQL e ripristinarlo:

$ psql -f dump_pg12.out postgres

Tieni presente che dovrai interrompere l'applicazione o evitare di scrivere nel database durante questo processo, altrimenti avrai dati incoerenti o una potenziale perdita di dati.

Utilizzo di pg_upgrade

In primo luogo, dovrai avere sia la nuova che la vecchia versione di PostgreSQL installata sul server.

$ 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

Quindi, per prima cosa, puoi eseguire pg_upgrade per testare l'aggiornamento aggiungendo il flag -c:

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

Le bandiere significano:

-b:la vecchia directory eseguibile di PostgreSQL
-B:La nuova directory eseguibile di PostgreSQL
-d:la vecchia directory di configurazione del cluster di database
-D:La nuova directory di configurazione del cluster di database
-c:controlla solo i cluster. Non cambia nessun dato

Se tutto sembra a posto, puoi eseguire lo stesso comando senza il flag -c e aggiornerà il tuo server PostgreSQL. Per questo, devi prima interrompere la tua versione corrente ed eseguire il comando menzionato.

$ 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

Quando è completato, come suggerisce il messaggio, puoi utilizzare quegli script per analizzare il nuovo server PostgreSQL ed eliminare quello vecchio quando è sicuro.

Utilizzo della replica logica

La replica logica è un metodo per replicare gli oggetti dati e le relative modifiche, in base alla loro identità di replica. Si basa su una modalità di pubblicazione e sottoscrizione, in cui uno o più abbonati si iscrivono a una o più pubblicazioni su un nodo editore.

Quindi, sulla base di questo, configuriamo il publisher, in questo caso il server PostgreSQL 12, come segue.

Modifica il file di configurazione postgresql.conf:

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

Modifica il file di configurazione pg_hba.conf:

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

Utilizza l'indirizzo IP dell'abbonato lì.

Ora devi configurare l'abbonato, in questo caso il server PostgreSQL 13, come segue.

Modifica il file di configurazione postgresql.conf:

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

Poiché questo PostgreSQL 13 sarà presto il nuovo nodo primario, dovresti considerare di aggiungere i parametri wal_level e archive_mode in questo passaggio, per evitare un nuovo riavvio del servizio in seguito.

wal_level = logical
archive_mode = on

Questi parametri saranno utili se vuoi aggiungere una nuova replica o per usare i backup PITR.

Alcune di queste modifiche richiedono il riavvio del server, quindi riavvia sia l'editore che l'abbonato.

Ora, nel publisher, devi creare l'utente che deve essere utilizzato dall'abbonato per accedervi. Il ruolo utilizzato per la connessione di replica deve avere l'attributo REPLICATION e, per poter copiare i dati iniziali, necessita anche del privilegio SELECT sulla tabella pubblicata:

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

Creiamo la pubblicazione pub1 nel nodo editore, per tutte le tabelle:

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

Poiché lo schema non viene replicato, è necessario eseguire un backup in PostgreSQL 12 e ripristinarlo in PostgreSQL 13. Il backup verrà eseguito solo per lo schema poiché le informazioni verranno replicate nell'iniziale trasferimento.

In PostgreSQL 12, esegui:

$ pg_dumpall -s > schema.sql

In PostgreSQL 13, esegui:

$ psql -d postgres -f schema.sql

Una volta che hai il tuo schema in PostgreSQL 13, devi creare la sottoscrizione, sostituendo i valori di host, dbname, user e password con quelli che corrispondono al tuo ambiente.

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

Ciò sopra avvierà il processo di replica, che sincronizza il contenuto della tabella iniziale delle tabelle nella pubblicazione e quindi inizia a replicare le modifiche incrementali a quelle tabelle.

Per verificare l'abbonamento creato puoi utilizzare il catalogo pg_stat_subscription. Questa visualizzazione conterrà una riga per sottoscrizione per il lavoratore principale (con PID nullo se il lavoratore non è in esecuzione) e righe aggiuntive per i lavoratori che gestiscono la copia dei dati iniziale delle tabelle sottoscritte.

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

Per verificare quando il trasferimento iniziale è terminato puoi controllare la variabile srsubstate sul catalogo pg_subscription_rel. Questo catalogo contiene lo stato di ogni relazione replicata in ogni sottoscrizione.

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)

Descrizioni delle colonne:

srsubid:riferimento all'abbonamento.
srrelid:riferimento alla relazione.
srsubstate:Codice di stato:i =inizializza, d =i dati vengono copiati, s =sincronizzati, r =pronto (replica normale).
srsublsn:termina LSN per gli stati s e r.

Al termine del trasferimento iniziale, hai tutto pronto per indirizzare la tua applicazione al tuo nuovo server PostgreSQL 13.

Conclusione

Come puoi vedere, PostgreSQL ha diverse opzioni per l'aggiornamento, a seconda dei tuoi requisiti e della tolleranza ai tempi di inattività.

Indipendentemente dal tipo di tecnologia che stai utilizzando, mantenere aggiornati i server di database eseguendo aggiornamenti regolari è un compito necessario ma difficile, poiché devi assicurarti di non perdere dati o incoerenza dei dati dopo l'aggiornamento. Un piano dettagliato e testato è la chiave qui e, naturalmente, deve includere un'opzione di ripristino, per ogni evenienza.