Metodi per aggiornare PostgreSQL a una nuova versione

Hostman Team

Technical writer

Database PostgreSQL

06.11.2025

Reading time: 8 min

In PostgreSQL, l'aggiornamento della versione può essere eseguito in modi diversi:

Installazione dei pacchetti con una nuova versione di PostgreSQL. Questo metodo è adatto solo per gli aggiornamenti minori. Prima di eseguire l'aggiornamento, consulta le note di rilascio.
Utilizzo del programma standard pg_dumpall. È un metodo affidabile, ma può causare tempi di inattività lunghi.
Utilizzo del programma standard pg_upgrade. Un altro modo veloce per aggiornare, ma possono verificarsi errori.
Aggiornamento tramite replica logica. Questa opzione ha tempi di inattività minimi, ma è adatta solo per le versioni di PostgreSQL superiori alla 10.0. Le versioni precedenti richiedono estensioni. La scelta dipende dalla versione utilizzata sul server e dalla versione a cui desideri aggiornare.
In questo articolo esamineremo tutti i metodi di aggiornamento sopra citati.

Note importanti prima dell'aggiornamento

È fondamentale comprendere le peculiarità degli aggiornamenti tra le diverse versioni.
I numeri di versione sono costituiti da due cifre, ad esempio, 10.1. La prima cifra è il numero di versione principale (10). La seconda cifra è il numero di versione minore (1).
Prima di PostgreSQL 10, i numeri di versione erano composti da tre cifre. Ad esempio, in 9.6.3, 9.6 è il numero di versione principale e 3 è il numero di versione minore.

È importante comprendere questa differenza per scegliere il metodo di aggiornamento appropriato.

Nelle versioni minori, il formato di archiviazione dei dati non cambia, quindi non ci sono problemi di compatibilità. Pertanto, la transizione da PostgreSQL 10.1 a 10.6 può avvenire molto facilmente. Per aggiornare, basta spegnere il server, sostituire i file eseguibili e riavviare il server. Tuttavia, la documentazione nota che alcune versioni potrebbero richiedere modifiche manuali. Pertanto, leggi sempre le note di rilascio prima di aggiornare.

Nelle versioni principali, il formato dei dati potrebbe cambiare. Questo rende l'aggiornamento più complesso. Sarà necessario scaricare i dati e caricarli di nuovo, utilizzare il programma pg_upgrade o utilizzare la replica logica.

Aggiornamento all'interno di una stessa versione principale

Vediamo come aggiornare PostgreSQL dalla versione 14.1 alla versione 14.3 su un server Ubuntu.

PostgreSQL è disponibile di default su Ubuntu. Inizia con il comando:

sudo apt-get upgrade

Debian e Ubuntu rilasciano una sola versione di PostgreSQL per ogni versione del sistema operativo. Ad esempio, Debian Squeeze/6.0 ha solo PostgreSQL 8.4. Se hai bisogno di una versione diversa di PostgreSQL, usa i pacchetti di PGDG.

Se desideri l'ultima versione di PostgreSQL, prima devi installare il repository Postgres.

Aggiungi il repository:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

Importa la chiave di firma:

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

Aggiorna la lista dei pacchetti nel sistema:

sudo apt-get update

Installa la versione richiesta di PostgreSQL:

sudo apt-get -y install postgresql-14.3

Per visualizzare l'elenco dei DBMS installati, esegui:

dpkg --get-selections | grep postgres

Visualizza anche l'elenco dei cluster:

pg_lsclusters

Arresta PostgreSQL prima di apportare modifiche:

sudo service postgresql stop

Quando i pacchetti di PostgreSQL sono installati, viene creato un cluster predefinito. Devi rinominare il nuovo cluster PostgreSQL in modo che non ci siano conflitti con il nome del vecchio cluster durante l'aggiornamento.

sudo pg_renamecluster 14.3 main main_pristine

Aggiorna il vecchio cluster:

sudo pg_upgradecluster 14.1 main

Avvia il servizio:

sudo service postgresql start

Controlla di nuovo l'elenco dei cluster e assicurati che il nuovo cluster funzioni:

pg_lsclusters

Elimina il vecchio cluster:

sudo pg_dropcluster 14.1 main

Aggiornamento tramite pg_dumpall

Se devi cambiare versione principale, usa il programma pg_dumpall. L'essenza di questo metodo è scaricare i dati da una versione principale e caricarli su un'altra.

Prima di scaricare i dati, assicurati che non vengano apportate modifiche alla base di dati in quel momento. In caso contrario, alcune modifiche potrebbero non essere incluse nel dump finale.

Ottieni il dump e scrivilo in un file:

pg_dumpall > output_file

Arresta il server:

pg_ctl stop

Cambia il nome della vecchia directory per evitare conflitti di nome:

mv /usr/local/pgsql /usr/local/pgsql.old

La vecchia directory può essere semplicemente eliminata. Ma sarebbe più saggio rinominarla per lasciare spazio al ripristino. Invece di /usr/local/pgsql, specifica il percorso della tua directory.

Installa la nuova versione dalle sorgenti. Esiste una guida dettagliata nella documentazione.

Crea un nuovo cluster:

/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

Trasferisci tutte le modifiche nei file pg_hba.conf e postgresql.conf.

Avvia il server di database:

/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data

Ripristina i dati dal backup:

/usr/local/pgsql/bin/psql -d postgres -f output_file

Lo svantaggio di questo metodo è che il server sarà spento per un lungo periodo. Per ridurre il tempo di inattività, puoi installare il nuovo server in una directory diversa e quindi eseguire i vecchi e nuovi server su porte diverse. Per trasferire i dati, usa il comando:

pg_dumpall -p 5432 | psql -d postgres -p 5433

Invece di 5432 e 5433, specifica i numeri di porta sui quali hai eseguito i server.

Aggiornamento tramite pg_upgrade

Per evitare di scaricare e ricaricare i dati, usa il programma pg_upgrade. Questo programma ti consente di aggiornare più velocemente. pg_upgrade crea di nuovo le tabelle di sistema, tenendo conto delle modifiche nelle versioni più recenti di PostgreSQL. In questo caso, i vecchi file di dati vengono mantenuti. Inoltre, pg_upgrade verifica che i cluster siano compatibili.

Il programma pg_upgrade ti aiuterà ad aggiornare da PostgreSQL 8.4.X alla versione attuale del DBMS.

Esaminiamo un piano di aggiornamento generale utilizzando pg_upgrade.

Sposta il vecchio cluster. Questo deve essere fatto se la directory non è stata collegata alla versione precedente. Ad esempio, si trova in /usr/local/pgsql. Se non lo rinomini, si verificherà un conflitto durante l'aggiornamento.

Il rinominamento viene effettuato quando il server è spento con il comando:

mv /usr/local/pgsql /usr/local/pgsql.old

Costruisci la nuova versione dalle sorgenti. Adatta il configure affinché le opzioni siano compatibili con la configurazione del cluster vecchio. Prima di avviare l'aggiornamento, pg_upgrade verificherà la compatibilità delle opzioni.

Installa i nuovi file eseguibili. Per collocare il server in una directory non standard, usa il prefisso:

make prefix=/usr/local/pgsql.new install

Usa initdb per inizializzare un nuovo cluster. Controlla che le opzioni siano compatibili con quelle del vecchio cluster.

Installa i file oggetti delle estensioni. Se sono disponibili aggiornamenti, pg_upgrade creerà automaticamente uno script per il loro successivo utilizzo.

Trasferisci i file di ricerca del testo completo.

Configura l'autenticazione peer in pg_hba.conf. Questo è necessario perché pg_upgrade si connetterà più volte agli host vecchi e nuovi.

Controlla che i vecchi e nuovi server siano spenti:

pg_ctl -D /opt/PostgreSQL/9.6 stop

pg_ctl -D /opt/PostgreSQL/14 stop

Esegui pg_upgrade dal nuovo server. Prima esegui il programma in modalità di controllo aggiungendo l'opzione: pg_upgrade --check. In risposta, riceverai un elenco degli aggiustamenti da fare manualmente dopo l'aggiornamento.

Se hai modificato il file pg_hba.conf, ripristinalo al suo stato precedente. A volte, altre configurazioni sul nuovo cluster devono essere modificate per corrispondere ai parametri del vecchio cluster.

Avvia il server.

Se sei soddisfatto del risultato, elimina il vecchio cluster.

Utilizzo della replica logica

A partire dalla versione 10 di PostgreSQL, abbiamo un metodo per la replica logica degli oggetti di dati e delle loro modifiche. Si basa sull'uso di identificatori di replica; solitamente, sono le chiavi primarie.

La replica logica utilizza il modello di pubblicazione-abbonamento. L'utente crea un'istantanea del database pubblicato e la copia nel sottoscrittore. Nella documentazione PostgreSQL, uno degli scenari tipici per utilizzare la replica logica è proprio la replica tra diverse versioni principali di PostgreSQL.

Il server di backup può essere posizionato sullo stesso host o su un altro. Una volta completata la sincronizzazione, sono disponibili diverse opzioni. Ad esempio, puoi rendere il nuovo server il principale e spegnere il vecchio.

Il principale vantaggio della replica logica è il tempo di inattività minimo. L'interruzione del server, in alcuni casi, è limitata a pochi secondi.

Conclusione

Abbiamo esaminato i metodi universali per aggiornare PostgreSQL a una nuova versione principale e aggiornare all'interno di una versione principale.

Con questa guida, puoi selezionare il metodo che funziona meglio per il tuo caso specifico e aggiornare la tua versione attuale di PostgreSQL.

Database PostgreSQL

06.11.2025

Reading time: 8 min

Simili

Piattaforma Kubernetes

Distribuire PostgreSQL su Kubernetes: guida passo per passo

PostgreSQL è un sistema di gestione di database relazionali (RDBMS) molto diffuso, che offre funzionalità di alta disponibilità come la replicazione in streaming, la replicazione logica e soluzioni di failover. Distribuire PostgreSQL su Kubernetes consente di creare sistemi resilienti, garantendo minimi tempi di inattività e disponibilità continua dei dati. Con gli StatefulSet di Kubernetes, è possibile scalare il deployment di PostgreSQL in base alla domanda. Choose hour server now! Configurazione dell’ambiente Kubernetes Assicurati di avere i seguenti componenti: Cluster Kubernetes (cloud o locale): puoi crearne uno su Hostman in pochi minuti. Se vuoi seguire la guida in locale, puoi utilizzare strumenti come k3s, minikube, microk8s o kind. kubectl: lo strumento da riga di comando per interagire con il cluster Kubernetes. Richiede un file YAML di configurazione che contiene i dettagli del cluster (solitamente fornito dal tuo provider). Puoi scaricarlo dal pannello di controllo di Hostman e impostare la variabile d’ambiente: Per connettersi, è necessario impostare di conseguenza la variabile di ambiente KUBECONFIG. export KUBECONFIG=/absolute/path/to/file/k8s-cluster-config.yaml Helm: è necessario lo strumento CLI di Helm per installare i chart. È richiesta la versione 3. Distribuire PostgreSQL utilizzando un chart Helm Helm è un gestore di pacchetti per Kubernetes, simile a apt su Ubuntu o Debian. Invece di creare manualmente più file YAML (Pods, Services, Volumi, Secrets, ecc.), Helm semplifica il tutto in un unico comando. Passaggio 1: Aggiungere il repository Helm helm repo add bitnami https://charts.bitnami.com/bitnami Per sincronizzare il repository Helm locale con quello remoto: helm repo update Passaggio 2: Gestire la persistenza dei dati PostgreSQL necessita di uno storage persistente per garantire che i dati rimangano disponibili anche se un pod si arresta o viene ripianificato. Crea il file postgres-local-pv.yaml: apiVersion: v1 kind: PersistentVolume metadata: name: postgresql-local-pv spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: manual hostPath: path: /mnt/data/postgresql ⚠️ Nota: hostPath fa riferimento a una directory locale di un nodo specifico. Se il nodo diventa inattivo, i dati non saranno più accessibili. Per gli ambienti di produzione, è fortemente consigliato usare soluzioni di storage cloud-native (Ceph, Portworx, OpenEBS, GlusterFS) per una maggiore affidabilità e scalabilità. Crea la PersistentVolumeClaim (PVC) — file postgres-local-pvc.yaml: apiVersion: v1 kind: PersistentVolumeClaim metadata: name: postgresql-local-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: manual Il parametro ReadWriteOnce permette l’accesso in lettura/scrittura da un solo nodo alla volta. L’utilizzo di ReadWriteMany (RWX) potrebbe sembrare utile per aumentare la disponibilità, ma in PostgreSQL può causare corruzione dei dati o stati incoerenti. Applica i manifest: kubectl apply -f postgres-local-pv.yamlkubectl apply -f postgres-local-pvc.yaml Passaggio 3: Installare PostgreSQL con Helm helm install tutorial-db bitnami/postgresql --set auth.username=bhuwan \ --set auth.password=”AeSeigh2gieshe” \ --set auth.database=k8s-tutorial \ --set auth.postgresPassword=”Ze4hahshez6dop9vaing” \ --set primary.persistence.existingClaim=postgresql-local-pvc \ --set volumePermissions.enabled=true Verifica dopo alcuni minuti: kubectl get all Passaggio 4: Test e connessione export POSTGRES_PASSWORD=$(kubectl get secret --namespace default tutorial-db-postgresql -o jsonpath="{.data.password}" | base64 -d) kubectl run tutorial-db-postgresql-client --rm --tty -i --restart='Never' \ --image docker.io/bitnami/postgresql:17.2.0-debian-12-r6 \ --env="PGPASSWORD=$POSTGRES_PASSWORD" \ --command -- psql --host tutorial-db-postgresql \ -U bhuwan -d k8s-tutorial -p 5432 Il pod verrà eliminato automaticamente grazie al flag --rm. 👉 Se hai modificato il nome del rilascio, l’utente o il database, aggiorna i comandi di conseguenza. Distribuire PostgreSQL su Kubernetes da zero Uno StatefulSet è la risorsa più adatta per distribuire applicazioni con stato, come PostgreSQL. Ogni pod ottiene un’identità di rete stabile e un volume persistente dedicato. Pulisci e ricrea le risorse: helm delete tutorial-db kubectl delete pvc postgresql-local-pvc kubectl delete pv postgresql-local-pv kubectl apply -f postgres-local-pv.yaml -f postgres-local-pvc.yaml Crea il file postgres-statefulset.yaml: apiVersion: apps/v1 kind: StatefulSet metadata: name: postgres-statefulset labels: app: postgres spec: serviceName: "postgresql-headless-svc" replicas: 1 selector: matchLabels: app: postgres template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres:17.2 envFrom: - secretRef: name: postgresql-secret ports: - containerPort: 5432 name: postgresdb volumeMounts: - name: pv-data mountPath: /var/lib/postgresql/db volumes: - name: pv-data persistentVolumeClaim: claimName: postgresql-local-pvc Crea il Secret per le credenziali: kubectl create secret generic postgresql-secret --from-literal=POSTGRES_PASSWORD=Ze4hahshez6dop9vaing kubectl apply -f postgres-statefulset.yaml Se il pod rimane in stato Pending, crea una StorageClass: kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: manual provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer Controlla eventuali problemi: kubectl describe pod postgres-statefulset-0 Crea un Headless Service per l’accesso interno — file postgres-service.yaml: apiVersion: v1 kind: Service metadata: name: postgresql-headless-svc spec: type: ClusterIP selector: app: postgres ports: - port: 5432 targetPort: 5432 clusterIP: None Test di connessione: kubectl run tutorial-db-postgresql-client --rm --tty -i --restart='Never' \ --image docker.io/bitnami/postgresql:17.2.0-debian-12-r6 \ --env="PGPASSWORD=Ze4hahshez6dop9vaing" \ --command -- psql --host postgres-statefulset-0.postgresql-headless-svc \ -U postgres -p 5432 Scalabilità, replica e backup Scalare lo StatefulSet: kubectl scale statefulset postgres-statefulset --replicas=3 Puoi accedere ai singoli pod tramite il servizio headless, ad esempio:postgres-statefulset-1.postgresql-headless-svc. Backup: utilizza un CronJob con l’utilità pg_dump. In alternativa, puoi abilitare VolumeSnapshots se il provider lo consente. Buone pratiche Resource Requests e Limits: imposta limiti di CPU e memoria appropriati. Backup regolari: usa CronJobs e snapshot. Monitoraggio e log: utilizza Prometheus e Grafana per raccogliere metriche (prestazioni delle query, utilizzo disco, stato della replica). Pod Disruption Budget (PDB): evita che troppi pod PostgreSQL vengano interrotti contemporaneamente durante aggiornamenti. Choose your server now! Conclusione Il chart Helm è il metodo consigliato per implementazioni complesse o in ambienti di produzione. Helm automatizza la gestione delle versioni e semplifica la configurazione delle risorse Kubernetes. Con il comando helm template, puoi generare localmente i manifest YAML e personalizzarli prima del deployment. Kubernetes offre scalabilità, flessibilità e automazione per PostgreSQL. Utilizzando StatefulSet, PVC, PDB e la gestione dei Secret, puoi ottenere un database PostgreSQL pronto per la produzione, affidabile e sicuro.

27 October 2025 · 7 min to read