Le aziende e le imprese che utilizzano le vecchie versioni di PostgreSQL (PG) devono affrontare delle difficoltà durante l'aggiornamento almeno alla versione stabile più recente da PostgreSQL 12 o PostgreSQL 13. Ci sono molte ragioni per cui l'aggiornamento all'ultima versione è un dovere. Alcuni dei motivi principali di ciò sono sfruttare i suoi miglioramenti critici alle sue funzionalità integrate, aggiornamenti di sicurezza, miglioramenti delle prestazioni e nuove implementazioni vantaggiose per la gestione del database.
L'aggiornamento di PostgreSQL comporta alcune sfide poiché non è così facile rispetto ad altri database tradizionali. Se stai affrontando questo tipo di problema, non preoccuparti. PostgreSQL non ti blocca su una versione specifica da utilizzare. In questo blog, illustreremo un esempio di questa sfida con un TimescaleDB e PostGIS installati su un host PostgreSQL 11 esistente.
Perché pg_upgrade?
pg_upgrade è in circolazione da molto tempo come strumento per l'aggiornamento delle versioni principali di PostgreSQL. L'utilizzo di questo strumento non è richiesto per gli aggiornamenti di versioni secondarie, il che significa che non è necessario aggiornare la versione corrente da 11.9 a 11.13.
Quando si aggiorna PostgreSQL a una versione principale con pg_upgrade, lo strumento funziona consentendo l'aggiornamento dei dati archiviati nei file di dati di PostgreSQL a una versione successiva di PostgreSQL principale. Funziona senza bisogno di un dump/ricarica dei dati, che può richiedere del tempo se si dispone di un grande set di dati.
Ora, ecco che arriva il clamore. PostgreSQL, in particolare per le versioni principali, è noto per avere nuove funzionalità aggiunte che spesso cambiano il layout delle tabelle di sistema, ma il formato di archiviazione dei dati interno cambia raramente. pg_upgrade utilizza questo fatto per eseguire aggiornamenti rapidi creando nuove tabelle di sistema e riutilizzando semplicemente i vecchi file di dati utente. Se una futura major release cambia il formato di archiviazione dei dati in modo da rendere illeggibile il vecchio formato dei dati, pg_upgrade non sarà utilizzabile per tali aggiornamenti. (La community cercherà di evitare tali situazioni.)
Alcuni potrebbero considerare pg_upgrade pericoloso, specialmente per l'ambiente di produzione. Bene, questo strumento è stato ampiamente utilizzato altrove, dal QA, allo sviluppo, agli ambienti di produzione. Ha i suoi limiti o avvertimenti, come l'Unicode noto o i set di caratteri archiviati nel set di dati. In tal caso, potresti prendere in considerazione l'utilizzo di pg_dump/pg_restore, ma il completamento può richiedere del tempo a seconda della dimensione dei tuoi dati. Per le versioni più recenti di PostgreSQL, come PG 14.0, puoi solo eseguire un dump/restore (o export/import) o una replica logica, altrimenti usa pg_upgrade.
Per set di dati più grandi, l'utilizzo di pg_upgrade richiede di eseguirlo sullo stesso host, che per impostazione predefinita applica una copia di tutti i file fisici dalla directory dei dati. In tal caso, pg_upgrade supporta l'opzione -k o --link, il che significa che utilizzerà i collegamenti reali invece di copiare i file nel nuovo cluster.
pg_upgrade fa del suo meglio per assicurarsi che i cluster vecchi e nuovi siano compatibili con i binari, ad esempio controllando le impostazioni compatibili in fase di compilazione, inclusi i binari a 32/64 bit. È anche importante che tutti i moduli esterni siano compatibili con i binari, sebbene ciò non possa essere verificato da pg_upgrade.
pg_upgrade supporta gli aggiornamenti da 8.4.X e versioni successive all'attuale versione principale di PostgreSQL, incluse le versioni snapshot e beta.
Ecco la situazione...
In questa configurazione, ho utilizzato ClusterControl per distribuire un cluster di database PostgreSQL 11 per un singolo nodo. I seguenti sono stati testati su Centos 7 e Ubuntu Focal (20.04.1):
$ /usr/pgsql-11/bin/postgres --version
postgres (PostgreSQL) 11.13
postgres=# \dx
List of installed extensions
Name | Version | Schema | Description
------------------------+---------+------------+-------------------------------------------------------------------
fuzzystrmatch | 1.1 | public | determine similarities and distance between strings
pg_stat_statements | 1.6 | public | track execution statistics of all SQL statements executed
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
postgis | 3.1.4 | public | PostGIS geometry and geography spatial types and functions
postgis_raster | 3.1.4 | public | PostGIS raster types and functions
postgis_sfcgal | 3.1.4 | public | PostGIS SFCGAL functions
postgis_tiger_geocoder | 3.1.4 | tiger | PostGIS tiger geocoder and reverse geocoder
postgis_topology | 3.1.4 | topology | PostGIS topology spatial types and functions
timescaledb | 2.3.1 | public | Enables scalable inserts and complex queries for time-series data
(9 rows)Quindi ho ottenuto quanto segue,
Versione del server PostgreSQL: 11.13
Versione TimescaleDB: 2.3.1
Versione PostGIS: 3.1.4
Se vuoi testarlo con ClusterControl, ci sono due modi per avere TimescaleDB. Puoi distribuire un cluster TimescaleDB o avere PostgreSQL e abilitare il plug-in TimescaleDB.
Configurazione per PostgreSQL 13
Utilizzare la configurazione del gestore pacchetti per l'ambiente Linux con il repository PostgreSQL e TimescaleDB è più semplice. Ecco i passaggi per farlo:
Imposta i repository richiesti
Per prima cosa, aggiungiamo il repository PostgreSQL.
Per CentOS/RHEL/Oracle Linux
Devi assicurarti di avere il repository giusto. Per Enterprise Linux (EL) 7, puoi fare quanto segue:
sudo yum -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpmPer altre architetture, puoi basarti qui https://download.postgresql.org/pub/repos/yum/reporpms/ e sostituire la sottodirectory EL-7-x86_64.
Aggiungiamo anche il repository TimescaleDB.
vi /etc/yum.repos.d/timescale_timescaledb.repoQuindi aggiungi i seguenti contenuti per questo file,
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/7/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300Sostituisci semplicemente l'URL di base di conseguenza se stai utilizzando una versione diversa da EL 7.
Per Ubuntu/Debian
Aggiungi il repository PG per Ubuntu Focal:
deb http://apt.postgresql.org/pub/repos/apt/ focal-pgdg mainPer altre distribuzioni Ubuntu/Debian, sostituisci semplicemente il focale di conseguenza, che puoi trovare qui http://apt.postgresql.org/pub/repos/apt/dists/. Ad esempio, sostituisci focal-pgdg con buster-pgdg.
Ora aggiungiamo il repository per TimescaleDB,
sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/timescale.keyring] https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -c -s) main' > /etc/apt/sources.list.d/timescaledb.list"Importa il portachiavi,
wget --quiet -O - https://packagecloud.io/timescale/timescaledb/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/timescale.keyringe aggiorna gli elenchi dei pacchetti per gli aggiornamenti per i pacchetti che devono essere aggiornati, nonché per i nuovi pacchetti che sono appena arrivati nei repository.
sudo apt-get updatePuoi sostituire la sottodirectory nell'URL se stai usando Debian da Ubuntu.
Ora che abbiamo il repository pronto, siamo a posto.
Installa PostgreSQL versione 13 con TimescaleDB e PostGIS
L'installazione di PostgreSQL 13 può essere eseguita sullo stesso host. Innanzitutto, devi assicurarti che elementi come la porta del database siano univoci. In altre parole, deve essere diverso dall'attuale PostgreSQL 11 installato sullo stesso host.
Per CentOS/RHEL/Oracle Linux
Esegui il comando seguente per installare PostgreSQL 13 e i suoi pacchetti dipendenti:
yum install postgresql13.x86_64 postgresql13-server.x86_64 postgresql13-contrib.x86_64 postgresql13-libs.x86_64 Quindi inizializza il cluster di database e la sua raccolta di database richiesta eseguendo il comando seguente:
$ /usr/pgsql-13/bin/postgresql-13-setup initdbA questo punto dovrebbero esserci due directory di dati sia per PG 11 che per PG 13:
[[email protected] ~]# ls -alth /var/lib/pgsql/* -d
drwx------. 4 postgres postgres 51 Sep 22 14:19 /var/lib/pgsql/13
drwx------. 4 postgres postgres 33 Sep 21 18:53 /var/lib/pgsql/11Ora che siamo bravi con PostgreSQL 13 installiamo TimescaleDB. Dobbiamo assicurarci che il plug-in da installare sia la stessa versione su PostreSQL 11.
Tieni presente che, per assicurarti che pg_upgrade funzioni senza problemi, i plugin della tua versione sorgente e di destinazione della versione principale dovrebbero essere la stessa versione. Questo perché pg_upgrade cercherà le sue librerie designate collegate ai plugin o alle estensioni che sono stati caricati o utilizzati dalla versione del database vecchio o di origine di PostgreSQL. Puoi verificarlo nel tuo Enterprise Linux eseguendo showduplicates o verificando con info proprio come di seguito con dnf o yum:
$ yum --showduplicates list timescaledb_13.x86_64 timescaledb-2-postgresql-13.x86_64 timescaledb-2-oss-postgresql-13.x86_64 timescaledb-2-loader-postgresql-13.x86_64|grep '2.3.1'
Repository pgdg-common is listed more than once in the configuration
timescaledb-2-loader-postgresql-13.x86_64 2.3.1-0.el7 timescale_timescaledb
timescaledb-2-oss-postgresql-13.x86_64 2.3.1-0.el7 timescale_timescaledb
timescaledb-2-postgresql-13.x86_64 2.3.1-0.el7 timescale_timescaledbOppure verificalo con l'opzione info:
$ yum info timescaledb-2-loader-postgresql-13-2.3.1-0.el7.x86_64 timescaledb-2-postgresql-13-2.3.1-0.el7.x86_64Ora siamo pronti per installare il pacchetto TimescaleDB per la versione PG 13.
$ yum install timescaledb-2-loader-postgresql-13-2.3.1-0.el7.x86_64 timescaledb-2-postgresql-13-2.3.1-0.el7.x86_64Dopo averlo installato, puoi provare a eseguire lo strumento timescaledb-tune per ottimizzare il tuo file di configurazione postgresql.conf. Basta eseguire il comando seguente:
$ timescaledb-tune --pg-config=/usr/pgsql-13/bin/pg_configOra installiamo il pacchetto PostGIS anche per la versione PG 13.
$ yum install -y postgis31_13.x86_64 Per Ubuntu/Debian
Esegui semplicemente:
$ apt install postgresql-client-13 postgresql-13La cosa grandiosa con le distribuzioni Ubuntu/Debian è che ci sono strumenti per PostgreSQL che sono molto utili per gestire i tuoi cluster PostgreSQL, come pg_lsclusters, pg_ctlcluster, ecc.
Puoi verificare i tuoi cluster disponibili installati.
$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
11 main 5432 online postgres /var/lib/postgresql/11/main log/postgresql-%Y-%m-%d_%H%M%S.log
13 main 5433 online postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.logIn Ubuntu/Debian, non è necessario modificare la porta poiché verrà gestita durante la fase di installazione e la rileva e la imposta in modo univoco, di conseguenza.
Ora installiamo TimescaleDB.
$ apt install timescaledb-2-loader-postgresql-13 timescaledb-2-postgresql-13Opzionalmente, puoi eseguire lo strumento timescaledb-tune per ottimizzare il tuo file di configurazione postgresql.conf semplicemente invocando lo strumento come segue:
$ timescaledb-tuneOra siamo pronti per installare il pacchetto PostGIS per PG 13.
$ apt install postgresql-13-postgis-3-scripts postgresql-13-postgis-3
Rivedi il tuo postgresql.conf
È sempre meglio rivedere il file di configurazione postgresql.conf. Nelle versioni Enterprise Linux, puoi individuare il tuo postgresql.conf nella tua directory_data o nel percorso PGDATA. Mentre per Ubuntu/Debian, puoi individuarlo in /etc/postgresql/
shared_preload_libraries = 'pg_stat_statements,timescaledb' # pg_stat_statements is not required but if you are using ClusterControl, make sure this is appended.
port = 5532 # make sure that the port number is unique than the old version of your PostgreSQL
listen_address = * # depends on your setup but if you need to specify the available network interfaces to its IP addresses (IPv4 or IPv6) set it accordingly.È consigliabile confrontare le vecchie e le nuove versioni dei file di configurazione di PostgreSQL per assicurarsi che postgresql.conf sia identico a ciò che è necessario e impostato.
Prima di procedere con il passaggio successivo, dobbiamo anche verificare che la versione 13 di PostgreSQL sia caricata di conseguenza. Assicurati di avere l'ultima versione acquisita o installata nel tuo host. Avvia il database e assicurati che si avvii e funzioni correttamente.
Per iniziare con le distribuzioni EL, esegui il comando seguente:
$ sudo -iu postgres /usr/pgsql-13/bin/pg_ctl -D /var/lib/pgsql/13/data/ -o "-c config_file=/var/lib/pgsql/13/data/postgresql.conf" starto per Ubuntu/Debian, esegui il comando seguente:
$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_ctl -D /var/lib/postgresql/13/main/ -o "-c config_file=/etc/postgresql/13/main/postgresql.conf" starto usa lo strumento pg_ctlcluster per avviare, riavviare o arrestare il tuo cluster PG.
Quando sei pronto, esegui pg_upgrade...
Prima di andare avanti, assicurati di avere sempre il backup del tuo vecchio server pronto e disponibile. Eseguire sempre un backup logico e fisico come buona pratica prima di procedere con un aggiornamento importante.
Ora che sei pronto, puoi eseguire pg_upgrade. In pratica, è necessario eseguire inizialmente pg_upgrade con un controllo per determinare l'incompatibilità e le problematiche prima di procedere alla procedura principale di pg_upgrade. Prima di eseguire pg_upgrade, assicurarsi che sia PG 11 che PG 13 siano inattivi durante questo processo. Ciò significa solo che sono necessari tempi di inattività per questo processo.
Per farlo, esegui il seguente comando con l'opzione --check:
$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_upgrade -o "-c config_file=/etc/postgresql/11/main/postgresql.conf" --old-datadir=/var/lib/postgresql/11/main/ -O "-c config_file=/etc/postgresql/13/main/postgresql.conf" --new-datadir=/var/lib/postgresql/13/main/ --old-bindir=/usr/lib/postgresql/11/bin --new-bindir=/usr/lib/postgresql/13/bin --checkSostituisci il valore --old-datadir o config_file di conseguenza se è diverso dalla tua configurazione.
Questo eseguirà i controlli di compatibilità proprio come il risultato seguente:
Performing Consistency Checks
-----------------------------
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 tables WITH OIDS ok
Checking for invalid "sql_identifier" user columns 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*Se tutti i controlli segnalano "ok", significa che il controllo è riuscito e il messaggio in basso mostra che i cluster sono compatibili, allora dovresti essere a posto.
Infine, esegui di nuovo il comando senza l'opzione --check:
$ sudo -iu postgres /usr/lib/postgresql/13/bin/pg_upgrade -o "-c config_file=/etc/postgresql/11/main/postgresql.conf" --old-datadir=/var/lib/postgresql/11/main/ -O "-c config_file=/etc/postgresql/13/main/postgresql.conf" --new-datadir=/var/lib/postgresql/13/main/ --old-bindir=/usr/lib/postgresql/11/bin --new-bindir=/usr/lib/postgresql/13/bin
Performing Consistency Checks
-----------------------------
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 tables WITH OIDS ok
Checking for invalid "sql_identifier" user columns ok
Creating dump of global objects ok
Creating dump of database schemas 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
If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.
Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows in the new cluster ok
Deleting files from new pg_xact ok
Copying old pg_xact to new server ok
Setting oldest XID for new cluster ok
Setting next transaction ID and epoch for new cluster ok
Deleting files from new pg_multixact/offsets ok
Copying old pg_multixact/offsets to new server ok
Deleting files from new pg_multixact/members ok
Copying old pg_multixact/members to new server ok
Setting next multixact ID and offset for new cluster ok
Resetting WAL archives ok
Setting frozenxid and minmxid counters in new cluster ok
Restoring global objects in the new cluster ok
Restoring database schemas in the new cluste ok
Copying user relation files ok
Setting next OID for new cluster ok
Sync data directory to disk ok
Creating script to analyze new cluster ok
Creating script to delete old cluster ok
Checking for extension updates notice
Your installation contains extensions that should be updated
with the ALTER EXTENSION command. The file
update_extensions.sql
when executed by psql by the database superuser will update
these extensions.
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.shA seconda delle dimensioni del tuo set di dati, potrebbe volerci un po' di tempo. Nel comando di esempio sopra, copia i registri delle transazioni, che sono file fisici. Tuttavia, se le dimensioni del tuo disco sono ridotte, puoi utilizzare l'opzione -k o --link, che utilizza collegamenti reali. Se tutto va bene, dovrebbe fornirti messaggi come quelli sopra che ti informano dell'aggiornamento completo e avvisi per aggiornare le estensioni che potresti avere. In questa configurazione, tutto procede senza intoppi. update_extensions.sql contiene solo quanto segue:
$ cat update_extensions.sql
\connect postgres
ALTER EXTENSION "pg_stat_statements" UPDATE;Come hai notato, pg_upgrade esegue una serie di azioni. Analizza tutte le righe dal cluster di origine, copiando i registri dei metadati delle transazioni e i relativi dati sullo stato delle transazioni multiple e il resto.
Una volta che hai capito che tutto sembra a posto, esegui lo script analysis_new_cluster.sh, che verrà eseguito
vacuumdb --all --analyze-only.
$ sudo -iu postgres PGPORT=5433 ./analyze_new_cluster.shTieni presente che dovresti specificare la porta di PostgreSQL 13 in modo che vacuumdb venga eseguito correttamente sul server di destinazione corretto.
In questo caso, il risultato dell'aggiornamento con le estensioni TimescaleDB e PostGIS abilitate va bene. Una volta che tutto appare in ordine, assicurati di avviare il server ed eseguire una serie di test e controlli.
Verifica il processo di aggiornamento
Verifica e rivedi sempre il processo di aggiornamento. Ecco alcune tabelle e un database definito dall'utente, che contiene hypertables e tabelle PostGIS che si basano sull'utilizzo di tipi e funzioni spaziali di geometria e geografia.
$ sudo -iu postgres psql -p5433
psql (13.4 (Ubuntu 13.4-1.pgdg20.04+1))
Type "help" for help.
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+---------+---------+-----------------------
mydb | postgres | UTF8 | C.UTF-8 | C.UTF-8 |
postgres | postgres | UTF8 | C.UTF-8 | C.UTF-8 |
template0 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | postgres=CTc/postgres+
| | | | | =c/postgres
(4 rows)
postgres=# \c mydb
You are now connected to database "mydb" as user "postgres".
mydb=# set search_path="$user",public;
SET
mydb=# \dt+
List of relations
Schema | Name | Type | Owner | Persistence | Size | Description
--------+-----------------+-------+----------+-------------+------------+-------------
public | conditions | table | postgres | permanent | 8192 bytes |
public | global_points | table | postgres | permanent | 16 kB |
public | roads | table | postgres | permanent | 16 kB |
public | sample_table | table | postgres | permanent | 8192 bytes |
public | spatial_ref_sys | table | postgres | permanent | 6968 kB |
(5 rows)Controllo di alcuni dei miei PostGIS e hypertables:
mydb=# \d roads
Table "public.roads"
Column | Type | Collation | Nullable | Default
------------+----------------------+-----------+----------+---------
road_id | integer | | |
road_name | character varying | | |
roads_geom | geometry(LineString) | | |
mydb=# \d sample_table
Table "public.sample_table"
Column | Type | Collation | Nullable | Default
--------+--------------------------+-----------+----------+------------------------------------------
id | integer | | not null | nextval('sample_table_id_seq'::regclass)
time | timestamp with time zone | | not null |
name | character varying | | not null |
Indexes:
"sample_table_pkey" PRIMARY KEY, btree (id, "time")
"sample_table_time_idx" btree ("time" DESC)
Triggers:
ts_insert_blocker BEFORE INSERT ON sample_table FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Number of child tables: 371 (Use \d+ to list them.)
mydb=# \d conditions
Table "public.conditions"
Column | Type | Collation | Nullable | Default
-------------+--------------------------+-----------+----------+---------
time | timestamp with time zone | | not null |
location | text | | not null |
location2 | character(10) | | not null |
temperature | double precision | | |
humidity | double precision | | |
Indexes:
"conditions_time_idx" btree ("time" DESC)
Triggers:
ts_insert_blocker BEFORE INSERT ON conditions FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Number of child tables: 366 (Use \d+ to list them.)
mydb=# select count(*) from sample_table;
count
-------
2588
(1 row)
mydb=# SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);
name
--------
Town
Forest
(2 rows)
mydb=# SELECT n, ST_AsEWKT(ST_GeometryN(the_geom, n)) As geomewkt
mydb-# FROM (
mydb(# VALUES (ST_GeomFromEWKT('MULTIPOINT(1 2 7, 3 4 7, 5 6 7, 8 9 10)') ),
mydb(# ( ST_GeomFromEWKT('MULTICURVE(CIRCULARSTRING(2.5 2.5,4.5 2.5, 3.5 3.5), (10 11, 12 11))') )
mydb(# )As foo(the_geom)
mydb-# CROSS JOIN generate_series(1,100) n
mydb-# WHERE n <= ST_NumGeometries(the_geom);
n | geomewkt
---+-----------------------------------------
1 | POINT(1 2 7)
1 | CIRCULARSTRING(2.5 2.5,4.5 2.5,3.5 3.5)
2 | POINT(3 4 7)
2 | LINESTRING(10 11,12 11)
3 | POINT(5 6 7)
4 | POINT(8 9 10)
(6 rows)Ora tutto sembra pronto per essere utilizzato come nuovo cluster.
Una volta che hai avviato le cose, puoi eseguire:
$ sudo -iu postgres ./delete_old_cluster.shAssicurati di eseguire solo lo script poiché si tratta di uno script molto pericoloso, poiché eliminerà tutti i file nel tuo vecchio cluster PostgreSQL.
Conclusione
pg_upgrade è un ottimo strumento per la gestione e l'aggiornamento del server di database PostgreSQL. Può gestire configurazioni complesse come con le estensioni TimescaleDB o PostGIS abilitate. Sebbene questo strumento abbia i suoi limiti, non puoi impedirti di usarlo, soprattutto per il tuo lavoro DBA e sui server di produzione oltre al QA e agli ambienti di sviluppo.
