Esistono sostanzialmente tre modi per aggiornare PostgreSQL da diverse versioni principali (ad es. Da 9.1 a 9.3).
Aggiornamento con pg_dump
Il primo, e se possibile consigliato, è fare un dump della versione precedente (9.1) usando il binario della versione più recente (9.3) e ripristinarlo su un nuovo cluster creato con la versione più recente.
Questo approccio è, generalmente, il più lento, ma anche il più possibile. Un consiglio per renderlo più veloce è usare la concorrenza. Per eseguire il dump con lavori paralleli, è possibile:
$ pg_dump --format=directory --jobs=4 --no-synchronized-snapshots --file=/path/to/mydump mydatabase
Dovrai farlo per ogni database che hai, adattare il --jobs=4
valore a qualsiasi valore (prova alcuni valori da 2 a numero di core e vedi quale dà una migliore velocità). Inoltre, durante questa fase, nessuno dovrebbe essere collegato al database, qualsiasi modifica comporterà un dump danneggiato (a causa dell'opzione non sicura --no-synchronized-snapshots
).
Successivamente, è possibile ripristinare il dump nella nuova istanza utilizzando pg_restore
:
$ createdb <options> -T template0 mydatabase
$ pg_restore --exit-on-error --jobs=4 --dbname=mydatabase /path/to/mydump
Successivamente, si consiglia di eseguire ANALYZE
sul database:
$ vacuumdb --analyze-only mydatabase
(se si può permettersi il tempo, eseguito solo --analyze
al anche VACUUM
il database e aggiornare la visibilità mappe)
Aggiornamento con pg_upgrade
Un'altra opzione è quella di utilizzare il contribpg_upgrade
. Utilizzando il --link
metodo fornisce un modo molto veloce per aggiornare PostgreSQL.
Prima di utilizzare devi fare un backup dell'intera directory di dati, perché in --link
modalità, se qualcosa va storto, potresti perdere entrambi i dati (vecchi e nuovi). Inoltre, leggi l'intero documento e specialmente le note in basso (ci sono alcune limitazioni per pg_upgrade).
AGGIORNAMENTO: utilizzare l' --check
opzione prima di eseguire il comando definitivo. Inoltre, per database di grandi dimensioni è consigliabile eseguire questo comando in una sessione dello schermo.
Esegui l'aggiornamento utilizzando uno strumento di replica basato su trigger
Un'altra opzione per aggiornare una versione è l'utilizzo di uno strumento di replica basato sul trigger. Come Slony, Bucardo e Londiste.
Questa è l'opzione che richiede il minor tempo di inattività possibile, ma è la più difficile su cui lavorare.
Per fare ciò è necessario creare un master-slave in cui il master è la versione corrente (9.1) e lo slave è la nuova versione (9.3). Quindi, attendi la prima sincronizzazione (con il sistema ancora in produzione), dopodiché chiudi tutti gli utenti collegati al database (il tempo di inattività inizia qui), attendi che lo slave riesca a raggiungerlo, promuovilo (lo slave) per masterizzare e reindirizzare tutti i client / applicazioni a questa nuova versione. E hai finito.
La documentazione di Slony fornisce una procedura dettagliata per aggiornare PostgreSQL usando Slony .
Quale scegliere
Bene, come sempre dipende, riprendendo:
- Il dump + restore è il più affidabile, ma generalmente il più lento (il parallelismo può dare buoni risultati)
- Pg_upgrade è una delle migliori opzioni per i tempi di inattività ridotti (se è possibile utilizzare, vedere le limitazioni), spesso sono necessari solo pochi minuti, anche per database di grandi dimensioni
- La replica del trigger è senza dubbio quella che offre il minor tempo di inattività possibile (vicino allo zero), ma è davvero difficile da realizzare e raccomando solo a persone esperte (sia su PostgreSQL sia sullo strumento di replica).
Spero di poterti aiutare. In bocca al lupo.