PostgreSQL 9.6 è appena stato rilasciato e la maggior parte degli utenti di Postgres inizieranno a chiedersi come aggiornare alla nuova versione principale. Questo post ha l'intenzione di mostrare diverse procedure per aggiornare il tuo server PostgreSQL.
L'aggiornamento a una nuova versione principale è un'attività che ha un alto rapporto di preparazione rispetto al tempo di esecuzione totale. In particolare quando si salta una versione nel mezzo, ad esempio, quando si passa dalla versione 9.3 alla versione 9.5.
Punti di rilascio
D'altra parte, gli aggiornamenti a rilascio graduale non richiedono tanta preparazione. In genere, l'unico requisito è il riavvio del servizio postgres. Non ci sono modifiche alla struttura dei dati sottostante, quindi non è necessario eseguire il dump e il ripristino. Nella peggiore delle ipotesi potrebbe essere necessario ricreare alcuni dei tuoi indici dopo aver terminato l'aggiornamento del rilascio graduale.
È molto saggio rimanere sempre sull'ultima versione del punto, in modo da non inciampare in un bug noto (e probabilmente risolto). Ciò significa che una volta rilasciata l'ultima versione, programma il tempo per l'aggiornamento il prima possibile.
Aggiornamento della versione principale
Quando si eseguono compiti complessi come questo, è bene considerare tutte le opzioni possibili per ottenere il risultato finale.
Per gli aggiornamenti delle versioni principali, puoi seguire tre possibili percorsi:
- Aggiorna il ripristino da un dump logico
- Aggiornamento fisico
- Aggiornamento in linea
Lascia che ti spieghi ciascuno in dettaglio:
1) Aggiorna il ripristino da un dump logico
Questo è il modo più semplice per aggiornare la struttura dei dati del tuo cluster.
Per farla breve, il processo qui richiede un dump logico usando pg_dump dalla vecchia versione e pg_restore su un cluster pulito creato con la versione appena installata.
I punti chiave a favore dell'utilizzo di questo percorso sono:
- È il più testato
- La compatibilità risale alle versioni 7.0, quindi potresti eventualmente aggiornare dalla 7.x a una delle versioni recenti
Motivi per cui dovresti evitare di usare questa opzione:
- Il tempo di inattività totale su database di grandi dimensioni può essere un problema, poiché devi interrompere le connessioni in scrittura prima di iniziare a eseguire pg_dump;
- Se ci sono molti oggetti di grandi dimensioni nel database, pg_dump sarà lento. Anche quando lo fai in parallelo. Il ripristino sarà ancora più lento di pg_dump quando nel database sono archiviati molti oggetti di grandi dimensioni;
- Richiede doppio spazio su disco o la rimozione del vecchio cluster prima del ripristino;
Su server con più core della CPU, è possibile eseguire pg_dump in parallelo utilizzando il formato directory. Una volta terminato, ripristina anche in parallelo, usando l'opzione -j sia in pg_dump che in pg_restore. Ma non puoi avviare il processo di ripristino finché l'intero dump non è terminato.
2) Upgrade fisico
Questo tipo di aggiornamenti è disponibile dalla versione 9.0 per eseguire aggiornamenti sul posto da versioni precedenti alla 8.3. Sono chiamati "sul posto" perché vengono eseguiti sullo stesso server e preferibilmente sulla stessa directory di dati.
Vantaggi di questo tipo di upgrade:
- Non hai bisogno di spazio per un'altra copia del cluster.
- I tempi di inattività sono molto inferiori rispetto all'utilizzo di pg_dump.
Ci sono alcuni svantaggi:
- Una volta avviata la nuova versione di PostgreSQL, non è più possibile tornare alla versione precedente (il cluster funzionerà solo con la nuova versione da lì in poi).
- Le statistiche vengono azzerate dopo l'aggiornamento, quindi subito dopo aver avviato la nuova versione di PostgreSQL deve essere eseguita un'analisi a livello di cluster.
- Negli ultimi anni sono stati rilevati molti bug relativi a pg_upgrade, il che rende alcuni amministratori di database riluttanti a utilizzare questo metodo per l'aggiornamento.
- Alcune persone hanno avuto problemi a saltare una versione principale, ad esempio passando dalla versione 9.2 alla versione 9.4.
- Con cataloghi di grandi dimensioni funzionerà male (cluster con molti database o database con molte migliaia di oggetti).
Puoi anche eseguire pg_upgrade senza l'opzione –link (in questo caso pg_upgrade genererà una seconda copia su disco del tuo cluster) in modo da poter tornare alla vecchia versione. Ma perderai entrambi i vantaggi sopra elencati.
3) Upgrade in linea
La procedura da seguire per questo metodo sarebbe la seguente:
- Installa entrambe le versioni in modo da poterle lavorare in parallelo. Questo può essere fatto sullo stesso server o utilizzando due server fisici.
- Crea una copia iniziale e replica le modifiche dal momento in cui hai avviato la copia sul nodo di origine (sarebbe simile a un pg_dump iniziale).
- Continua a replicare logicamente le modifiche finché il ritardo non è prossimo allo zero.
- Riindirizza le informazioni di connessione dal server delle applicazioni per connettersi al nuovo server.
Questo tipo di aggiornamento è disponibile da quando esistevano le prime soluzioni di replica basate su trigger. In altre parole, da quando Slony-io c'ero.
Le soluzioni di replica basate su trigger non si preoccupano della versione che hai da una parte o dall'altra, poiché copia le modifiche utilizzando i comandi SQL supportati.
Gli strumenti di replica basati su trigger consigliati, nell'ordine in cui appaiono sono:
- skytools:PgQ + londiste
- Slony-I
Questo dovrebbe essere il modo preferito per l'aggiornamento. Vediamo i vantaggi dell'utilizzo di questo metodo:
- Zero tempi di inattività!
- Ottimo anche per l'aggiornamento a hardware più recente.
- Test in linea del cluster con la nuova versione (query di sola lettura, altrimenti potresti avere conflitti).
- Riduce drasticamente tutti i rigonfiamenti di tabelle e indici.
Ci sono alcuni svantaggi:
- Richiede doppio spazio di archiviazione, poiché deve archiviare una seconda copia dei tuoi dati.
- Poiché si basa sui trigger, il sistema deve scrivere ogni modifica due volte, il che significa che ci sarà più I/O del disco sul server di origine (versione precedente del cluster).
- Tutte le tabelle devono avere una chiave primaria, quindi lo strumento di replica può individuare le tuple che vengono aggiornate o eliminate
- Non replica le tabelle del catalogo, quindi non replicherà oggetti di grandi dimensioni.
- L'uso di base non copre le modifiche allo schema. Si può fare, ma non in modo trasparente.
Una nuova frontiera con pglogical
Da PostgreSQL 9.4 abbiamo la decodifica logica dei log delle transazioni. Ciò significa che ora possiamo decodificare le transazioni dal WAL e manipolare l'output.
Un intero nuovo mondo di possibilità è apparso nel campo della replicazione. I trigger non sono più necessari per eseguire la replica logica!
Ciò significa sostanzialmente che non è più necessario salvare una copia separata di tutti gli inserimenti, gli aggiornamenti e le eliminazioni utilizzando i trigger. Puoi semplicemente ottenere quelle operazioni di manipolazione dei dati dai registri delle transazioni, decodificandolo. Quindi, è lo strumento che stai utilizzando che deve manipolare l'output e inviarlo al nodo downstream sottoscritto. In questo caso quello strumento è pglogico.
Allora, cosa significa tutto questo?
Bene, se utilizzi una versione 9.4 o 9.5 di PostgreSQL e desideri eseguire l'aggiornamento alla 9.6, puoi eseguire un aggiornamento online come quello descritto sopra, ma utilizzando pglogical invece di una delle soluzioni di replica basate su trigger.
Non entrerò nei dettagli poiché ci sono altri blog su questo particolare argomento, come questo scritto da Petr Jelinek:PGLogical 1.1 packages for PostgreSQL 9.6beta1
Conclusioni
A seconda dello schema del database, della dimensione dei dati, della possibile finestra temporale di inattività, della versione dell'installazione corrente di PostgreSQL, potresti scegliere un'opzione rispetto a un'altra o quella che si adatta meglio.
- Se il tuo database è piccolo e c'è una finestra di manutenzione adatta che puoi usare, puoi optare per l'esecuzione di pg_dump e pg_restore. A seconda delle dimensioni del set di dati, c'è un punto in cui l'opzione non è più fattibile.
- Se disponi di un database di grandi dimensioni (diverse centinaia di GB o addirittura TB di dati) dovrai cercare altre opzioni come un aggiornamento sul posto con pg_upgrade o un aggiornamento online.
- Se si esegue l'aggiornamento dalla versione 8.3 o successiva a qualsiasi versione 9.x, è possibile utilizzare pg_upgrade.
- Per le versioni precedenti alla 8.3, dovrai optare per una delle soluzioni di replica logica come londiste o slony.
- Se hai un database 9.4 o 9.5 è meglio usare pglogical.
Ricorda sempre che per la replica logica le tabelle devono avere una chiave primaria.
Con pglogical quella regola non è così rigida:puoi replicare tabelle di solo inserimento. Ma per gli aggiornamenti e le eliminazioni, è comunque obbligatorio avere una chiave primaria o un'IDENTITÀ REPLICA sul tavolo.
Se hai bisogno di aiuto per aggiornare il tuo database PostgreSQL, puoi controllare i
2ndQuadrant Upgrade services.
