Il pannello di controllo di Literate Computing ha aggiornato con successo due siti standalone e un sito a due container senza incidenti. Per lo più, tutto ciò che era necessario era cambiare la versione target di Postgres in una variabile, quindi, come annunciato, il processo è lo stesso degli ultimi aggiornamenti.
In realtà è piuttosto supportato, è molto più sicuro rispetto all’aggiornamento di una versione principale del database. Se qualcosa va storto, non devi semplicemente passare al nuovo server. Se sei vicino alla necessità di un aggiornamento del sistema operativo e/o vuoi un tempo di inattività minimo, è un buon approccio. Hai accesso in sola lettura mentre costruisci il nuovo server e poi passi a quello. Il metodo semplice prevede solo un tempo di inattività per la ricostruzione finale, o zero tempo di inattività se copi i certificati dal vecchio server).
Se tutto va male con un aggiornamento del database, costruire un nuovo server e ripristinare il backup è la soluzione più semplice.
Assicurati di fare un backup prima di iniziare. Faccio un backup solo del database poiché non perderai i tuoi upload.
Solo per confermare, non sto usando PostgreSQL fornito da Discourse e Discourse stesso non richiede ancora PG18, giusto? Quindi non sono (ancora) tenuto ad aggiornare a PG18.
Buon punto. Ma l’altro aspetto è che le versioni LTS vengono rilasciate ogni paio di anni, quindi non è una cattiva idea procedere con l’aggiornamento allo stesso tempo.
Hai sicuramente ancora tempo. Hanno spinto per… ehm, un rilascio piuttosto veloce dopo l’aggiornamento a causa di una funzionalità richiesta, ma probabilmente puoi aspettare fino a un anno. Tengo d’occhio il repository discourse_docker. A un certo punto inizieranno a parlare della rimozione del supporto per PG15; non è particolarmente rumoroso ed è un modo semplice per restare aggiornati sulle modifiche interne.
Questo potrebbe incoraggiare altri a seguire le nostre intraprendenti orme più rapidamente.
La mia AI di ricerca web gratuita mi dice:
Per un’applicazione Rails tipica, il passaggio da PostgreSQL 15 a 18 può garantire ~10–25% di prestazioni di query più veloci senza modifiche al codice, e fino al 40% in specifici pattern di query se si sfruttano le nuove funzionalità di indicizzazione e pianificazione.
Se è vero, è un aggiornamento piuttosto significativo!
Vero, ma il nostro obiettivo è un meccanismo di aggiornamento semplice e trasparente. Ci sono vantaggi in entrambi i casi.
Direi di fare ciò che ti sembra più comodo e non avere paura di personalizzare i template in discourse_docker in base alle tue esigenze. Ovviamente la chiave è testare prima e avere un piano di rollback.
Sulla nostra piattaforma hostata intendiamo eseguire più test e benchmarking prima di abilitarli, e quindi li ho disabilitati anche in discourse_docker per allineare la configurazione. Non è strettamente necessario disabilitarli (internamente utilizziamo solo la parte del contenitore web di discourse_docker) e non sarei contrario ad abilitarli.
Un potenziale problema è che pg_upgrade non funzionerà se le directory dei dati vecchia e nuova hanno impostazioni di checksum diverse. Il processo dovrebbe essere quello di arrestare il server PG15, eseguire pg_upgrade per convertirlo in PG18 senza checksum, eseguire pg_checksums per abilitare i checksum e quindi avviare PG18. Questo non è un problema quando si esegue un dump e restore (come in questo aggiornamento) ma è qualcosa a cui fare attenzione.
Nota che i checksum dei dati sono disponibili da Postgres 9.3 ma fino ad ora sono stati disabilitati per impostazione predefinita. Postgres 19 includerà anche la possibilità di abilitarli/disabilitarli online.
Al momento no. La maggior parte delle funzionalità di Discourse utilizza l’adattatore PostgreSQL di Rails per comunicare con il DB, ma il backup/restore utilizza pg_dump e psql nel contenitore web. Al momento stiamo installando sia i client PG15 che PG18 per abilitare il backup/restore utilizzando entrambe queste versioni, ma in un momento futuro rimuoveremo PG15.
Il fattore trainante è stato il passaggio al nuovo provider locale integrato. Stiamo lavorando verso un aggiornamento del sistema operativo sulla nostra piattaforma hostata e vogliamo interrompere l’accoppiamento con glibc.
e7f1201 ha aggiunto il client PG18 all’immagine web per garantire la compatibilità dei backup. Se non stai utilizzando nessuno dei componenti del server Postgres di discourse_docker, questa è la revisione più antica che dovresti utilizzare per PG18.
D’accordo. Il mio punto era semplicemente che non è meno supportato poter ripristinare un backup postgres più vecchio su una versione più recente. Il meccanismo di aggiornamento in-place funziona in modo incredibile per la stragrande maggioranza delle persone, ma quando qualcosa va storto, è difficile sapere cosa fare (principalmente perché accade così raramente).
