Stiamo gestendo un’installazione di Discourse più grande su una configurazione VPS che fondamentalmente funziona molto bene per noi. In termini di prestazioni di CPU/Mem abbiamo margine. Lo spazio su disco, tuttavia, è un po’ un problema - non nelle attività quotidiane, ma quando si tratta di aggiornare Postgres, ad esempio (l’aggiornamento da 13 a 15 è in sospeso a causa di questo) ci manca lo spazio e non possiamo espanderlo facilmente.
So che ci sono altre opzioni per l’aggiornamento di postgres, ma considera questa più come una domanda generale.
Stiamo operando su Hetzner, dove l’archiviazione di rete è facilmente disponibile per l’uso temporaneo.
Sul nostro server di test sto sperimentando per farlo funzionare in modo temporaneo - prima per ripristinare un backup dal sito live, poi per testare l’aggiornamento di Postgres. Finora non ho avuto successo.
Ho già provato a creare dei symlink (collegamenti simbolici) ma ho notato che non ha funzionato e ho anche letto da qualche parte che non è il modo raccomandato. Ho anche provato a spostare la condivisione /shared da /var/discourse/shared/standalone a /mnt/ext-storage/standalone e ho spostato i file lì - sfortunatamente non senza problemi. Non riesco nemmeno a finire la build.
C’è un modo che funzioni per questo tipo di casi? Sono consapevole che le prestazioni del disco sono molto peggiori del disco locale, ma non ho intenzione di eseguire il forum su di esso. Mi piacerebbe davvero avere un modo comodo per usarlo per determinati scenari.
Se il tuo obiettivo è eseguire l’aggiornamento, la cosa più semplice è avviare una nuova vm e migrare su di essa. Eviti la necessità di aggiornare il database e ottieni un nuovo sistema operativo sulla tua vm, cosa che probabilmente dovrai fare comunque.
Se i tuoi backup sono su s3 è molto semplice bloccare quello vecchio, fare un backup e ripristinare il backup sulla nuova macchina.
Se hetzner ha una sorta di ip permanente che può essere assegnato a server diversi, non devi nemmeno cambiare il dns.
Vuoi sapere che puoi costruire un nuovo server in modo che se mai dovessi per qualche motivo potrai farlo. Questa è un’ottima occasione per fare pratica.
In realtà questa non è un’opzione. Non sta esaurendo lo spazio per le necessità quotidiane comunque. Inoltre, al momento siamo su un disco da 600 GB e ne stiamo utilizzando circa il 50%. Non c’è un’opzione più grande, almeno non su Hetzner.
Ecco perché chiedevo esplicitamente il disco esterno.
Non stavo suggerendo di passare a un disco più grande, solo di procurarsi un nuovo server esattamente come quello. Installare Discourse, ripristinare il tuo database.
Questa è un’ottima domanda.
Sì. Ogni ricostruzione crea un nuovo container e ognuno di essi occupa spazio. Se non l’hai mai fatto, potresti liberare decine di GB.
La nostra guida all’aggiornamento include una guida per il tuo caso d’uso esatto.
Abbiamo aggiunto questa opzione per le persone che si trovano nella tua stessa situazione. Assicurati solo di archiviare un backup offsite prima di provare!
Apprezzo i vostri consigli.\n\n[quote="Falco, post:8, topic:351878, username:Falco"]\nAbbiamo aggiunto questa opzione per le persone nella tua stessa situazione. Assicurati solo di salvare un backup offsite prima di provare!\n[/quote]\n\nGrazie, è l’altra opzione di cui ero a conoscenza. Grazie comunque per averla segnalata.\n\n[quote="Jay Pfaffman, post:9, topic:351878, username:pfaffman"]\nSe sei su una VM, è molto, molto più facile spostarsi su una nuova, e ci sono molti vantaggi.\n[/quote]\n\nNon lo metto in dubbio, avrei comunque voluto esplorare l’opzione di aggiungere spazio di archiviazione aggiuntivo per le attività di manutenzione, se necessario.
Può essere utile conservare i tuoi upload, o, diciamo /var/discourse/shared/web_only, su uno storage di rete. Devi modificare il file yml per puntare ad esso invece di usare un symlink (il symlink non funziona perché il container non può accedere al posto a cui punta il tuo symlink).
Quindi, se ti sposti su una nuova vm, puoi semplicemente rimontare quello storage di rete invece di copiarlo.
Non consiglio lo storage di rete per il database poiché è più lento.
Penso che valga la pena analizzare come viene utilizzato lo spazio. La dimensione effettiva del tuo database potrebbe non essere così grande, se la maggior parte del tuo utilizzo riguarda i caricamenti, e solo la parte del database richiede circa 3 volte lo spazio durante l’aggiornamento.
Una cosa che puoi controllare è la dimensione relativa di un backup con download rispetto a un backup senza download.
Oppure, usa la riga di comando. Ecco alcuni output del mio forum, piuttosto piccolo:
Sarei dovuto essere più preciso inizialmente, ma non mi aspettavo di ricevere un feedback così diffuso.
I nostri caricamenti e backup sono su S3. La dimensione del database sul sistema live è ora di circa 230 GB. I backup compressi sono di circa 25 GB, credo.
Penso che dovrebbe. Non mi è chiaro cosa lo attivi. Penso che farne uno extra non faccia male e possa farti risparmiare un po’ di spazio. È consigliato dopo l’aggiornamento se lo fai sul posto. L’ho visto ripulire uno spazio considerevole un paio di volte.
Se il tuo database è di 230 GB, lo ripristinerei sicuramente su un nuovo server. Il tempo di inattività per la lettura e la scrittura di 230 GB sarà significativo.