5 risposte

Non fare un semplice pg_dump e restore in un database vuoto se non vuoi stare con downtime di ore - invece usa pg_upgrade che gira sullo stesso server senza bisogno di esportare/importare, o se vuoi migrare a un altro server usa la replica logica per mantenere l'app in funzione mentre si sincronizza. Con 50GB vai a risparmiare un sacco di tempo e stress facendolo in quel modo.

La tua applicazione può stare un po' senza scrivere sul DB o hai bisogno di zero downtime assoluto? Se puoi fermare le scritture anche solo per 5-10 minuti, pg_upgrade è la tua migliore amica perché converte i file sullo stesso disco senza esportare nulla, quindi con 50GB ti risparmi ore. Adesso, se hai bisogno di evitare il downtime completamente, c'è un trucco che pochi mencionano: puoi usare la replica logica (logical replication) per sincronizzare il DB vecchio con quello nuovo in parallelo mentre continua a girare, e poi fai lo switch quando è tutto al giorno - è un po' più complicato da configurare ma è oro se non puoi fermare il servizio. Detto questo, prima di qualsiasi cosa testalo in un ambiente di staging anche solo con un dump di alcuni GB per vedere quanto tempo ci mette nel tuo setup specifico.

DiegoHernandez asker Possiamo fermare le scritture per 10 minuti senza problemi. Allora provo pg_upgrade, grazie per l'informazione.

Hai già verificato che la tua versione 12 è compatibile direttamente con la 15, o devi passare per versioni intermedie? Quello che nessuno menziona è che oltre a pg_upgrade, dovresti considerare di fare un backup completo prima di qualsiasi cosa, perché anche se pg_upgrade è abbastanza affidabile, avere quel backup ti dà tranquillità - soprattutto con 50GB. Se davvero devi evitare un downtime totale, esiste la replica logica (logical replication) dove configuri un'istanza secondaria con la versione 15, la sincronizzi in parallelo e poi fai il failover quando è pronta, ma è più complesso. La maggior parte della gente che conosco finisce per scegliere pg_upgrade con una finestra di manutenzione breve perché è la soluzione più pratica e veloce per un volume così.

Con 50GB devi stare attento ma pg_upgrade è davvero l'opzione giusta se riesci a tollerare un downtime di 5-10 minuti. Quello che la maggior parte non menciona è che da PostgreSQL 12 a 15 è un salto che pg_upgrade gestisce senza problemi in una sola passata, quindi non hai bisogno di versioni intermedie. Il mio consiglio: prima di fare qualsiasi cosa, fai un backup completo con pg_basebackup o pg_dump in parallelo (usa pg_dump con l'opzione -j per parallelizzare, riduce parecchio i tempi), e poi sì esegui pg_upgrade sul tuo server di produzione durante una finestra di manutenzione. Però, dopo l'upgrade lancia ANALYZE sulle tabelle grandi perché cambiano alcune statistiche interne e potresti avere query lente se non lo fai.

Ascolta, se riesci a tollerare anche solo 10-15 minuti di downtime, pg_upgrade è decisamente la strada giusta perché fa la migrazione sullo stesso server senza esportare/importare tutti i dati (con 50GB ti risparmi un sacco di tempo). Quello che nessuno ha menzionato qui è che prima di qualsiasi cosa devi controllare se ci sono estensioni installate che non siano compatibili tra le versioni, perché quello può bloccare tutto il processo all'ultimo momento e lasciarti con sorprese spiacevoli quando sei già nella conversione. La mia raccomandazione: fai un backup completo con pg_basebackup comunque (tanto per sicurezza), testa tutto su un server di staging prima, e poi sì, lanciati con pg_upgrade in produzione.

La tua risposta

Accediper rispondere.