Lascia semplicemente che Discourse se ne occupi. Questo richiede 3 volte lo spazio su disco. Quindi, se il tuo database è di 100 GB, avresti bisogno di ulteriori 200 GB liberi per eseguire l’aggiornamento. Ovviamente un enorme problema per chi ha installazioni di grandi dimensioni.
Segui la loro procedura di “aggiornamento manuale”. Questo richiede 2 volte lo spazio su disco, quindi se il tuo database è di 100 GB avresti bisogno di ulteriori 100 GB liberi. Anche questo è un grosso problema per alcuni.
In questo post, @Falco ha suggerito di utilizzare l’opzione --link per eseguire l’aggiornamento in-place utilizzando collegamenti fisici. Il container docker che suggeriscono di utilizzare supporta quell’argomento, ma gli sviluppatori di Discourse non lo raccomandano nel post.
Quindi la mia domanda è questa: l’opzione 3 dovrebbe essere:
Esegui il comando qui sotto, che richiederà una quantità molto piccola di spazio su disco aggiuntivo. Quindi, se il tuo database è di 100 GB, potrebbe richiedere, ad esempio, ulteriori 10 GB? E in tal caso, questa è una procedura raccomandata dagli sviluppatori di Discourse, e qualcuno l’ha effettivamente eseguita in passato ed è sopravvissuto per raccontarlo?
Comando nuovo per l’aggiornamento in-place:
docker run --rm \
-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
tianon/postgres-upgrade:12-to-13 \
--link
Confrontato con il comando vecchio per l’aggiornamento in una nuova directory (richiedendo il doppio dello spazio):
P.S.: Avrei semplicemente risposto a quel thread sull’aggiornamento a PG13, ma elimina i post dopo 7 giorni. Perché è configurato in questo modo? So che all’inizio c’è stata molta discussione che sarebbe stata utile come riferimento.
Se l’avessero fatto, non l’hanno menzionato qui. Le istruzioni qui presenti cercano di essere il più possibile a prova di errore e richiedono la minima conoscenza possibile di amministrazione di sistema. La maggior parte delle persone preferisce fare le cose nel modo più sicuro e più testato possibile, piuttosto che in un modo progettato per risparmiare pochi dollari.
Se funziona per te, puoi aggiornare l’aggiornamento a PostgreSQL 13 di conseguenza, ma prima di farlo, ti senti a tuo agio nel raccomandare a qualcuno che non sa cos’è bash di procedere in quel modo? Sei sicuro che non distruggerà il loro database e che il loro sito non sarà rovinato per sempre?
L’idea è che, se vengono presentate altre informazioni utili, queste vengano aggiunte all’OP (post originale) piuttosto che chiedere alle persone di leggere mesi di post che potrebbero essere inutili o errati.
No, non ne sono sicuro; non ho molta esperienza con PostgreSQL e speravo che uno degli sviluppatori di Discourse potesse dare alcune rassicurazioni sul fatto che funzionerebbe.
Anche se funziona, non lo raccomanderei come procedura di aggiornamento predefinita, poiché il metodo precedente mantiene una copia separata del database per il rollback. Se funziona, sarebbe comunque un’ottima opzione per ambienti con spazio limitato.
Un altro modo semplice è avviare un nuovo server, migrare i dati e disattivare quello vecchio. Se devi per forza utilizzare il vecchio, esegui l’aggiornamento su un server temporaneo: fai così un’installazione pulita sul server originale (che probabilmente necessita di un aggiornamento del sistema operativo) e poi riportaci i dati.
È sicuro, semplice e ben documentato. Centinaia di persone l’hanno già fatto.
Sì, ma ci vorrebbe un giorno o due. In quel periodo potremmo o a) comunicare agli utenti che i loro post di questo periodo andranno persi o b) impostare il forum in sola lettura. Nessuna delle due è una soluzione ideale.
Non credo che il server rimarrà offline molto più a lungo rispetto al periodo di ricostruzione. Inoltre, se sposti tutto sul nuovo server e ci rimani, puoi lasciare il vecchio server in modalità sola lettura mentre effettui la migrazione. Se il tuo timore è il tempo di inattività, passare a un nuovo server sarà molto, molto meglio.
Abbiamo un forum piuttosto grande, ma non ho mai provato a ripristinare un backup, quindi non so quanto tempo ci vorrebbe. Se lo facessimo, rimarremmo effettivamente sul nuovo host. Vorrei evitarlo, se possibile, per il lavoro extra e i disagi che comporterebbe.
Un altro modo per risolvere il problema dell’aggiornamento con spazio limitato è eseguire un backup, eliminare la directory postgres con rm -r, ricrearla e quindi ripristinare il backup. L’ho fatto su un sito la scorsa settimana.
No, non è mai stato aggiornato. Eliminare il database e ripristinare il backup sembra piuttosto rischioso. Abbiamo bisogno che l’aggiornamento sul posto funzioni, fondamentalmente.
Stiamo eseguendo Ubuntu 18.04 che verrà dismesso nel 2023, quindi immagino che a quel punto non avremo altra scelta che migrare su un nuovo host, e prevediamo di affrontare il problema allora, costruire un nuovo host con Ubuntu 22.04 LTS e ripristinare dal backup.
Hmm. Potrebbe essere un lavaggio. Penso che con il modello di backup una delle copie sia compressa, il che potrebbe fare la differenza? E il sito su cui l’ho fatto aveva backup su S3. Ed era un sito di test, quindi la posta in gioco era bassa se c’era un problema.
Tranne che i backup vengono utilizzati molto più spesso in molte più situazioni rispetto all’aggiornamento sul posto. Lo considero molto più sicuro.
Forse, ma non ho molta esperienza con postgres e non mi sento a mio agio a farlo. Ripristinare l’intero sito dal backup su una VM completamente diversa, quello mi sento a mio agio a farlo, tuttavia significherebbe perdere post per quante ore ci vorranno per ripristinare, quindi non sono nemmeno super entusiasta di questo. Ma dato che 18.04 non sarà più supportato, non avrò molta scelta l’anno prossimo.
A meno che il tuo database non sia di decine di gigabyte, non ci vorranno ore. E metterai il forum in modalità di sola lettura prima di eseguire il backup e il ripristino, quindi non perderai alcun post. Non è così difficile da fare con tempi di inattività virtualmente nulli, solo tempi di sola lettura.
root@forum-app:/shared/postgres_data# du -sh
97G .
Non lo metterei in sola lettura, ma piuttosto visualizzerei un banner che avvisa le persone che i loro post di oggi sono effimeri. Meglio lasciarli chattare anche se quei post andrebbero persi, secondo me.
A quel punto avrai accesso anche alla chat integrata di Discourse, una funzionalità che verrà rilasciata con la versione 2.9 (possibilmente disattivata per impostazione predefinita, ma in beta e supportata per l’uso).