Pulizia del database prima dell'aggiornamento a PostgreSQL 18: periodo di conservazione consigliato per le tabelle di log/statistiche?

[scavin]

Ciao a tutti,

Ho visto la guida per l’aggiornamento a PostgreSQL 18 per le istanze Discourse self-hosted:

Aggiornamento PostgreSQL 18 per chi ospita in proprio

ATTENZIONE! Se il tuo database è molto grande, avrai bisogno di molto spazio extra su disco (3 volte la dimensione del database) e dovrai prestare molta attenzione durante questo aggiornamento! Abbiamo appena implementato le modifiche per aggiornare la nostra immagine Docker a PostgreSQL 18. Tutti gli amministratori di sito che ricostruiscono Discourse dalla riga di comando verranno aggiornati da PostgreSQL 15 a PostgreSQL 18. Nota che se hai rimandato l’aggiornamento quando è usc…

Viene menzionato che il processo di aggiornamento richiede una quantità significativa di spazio aggiuntivo su disco, quindi ho iniziato a controllare l’utilizzo del disco e la dimensione del database prima di tentare la migrazione.

Il mio attuale utilizzo del disco:

/dev/sda1        97G   44G   54G  45% /

La dimensione del mio database Discourse è di circa 21 GB. Ho scoperto che la maggior parte dello spazio non è utilizzata dai post, ma da diverse tabelle di statistiche e log.

Le tabelle più grandi sono:

topic_views              5,2 GB
post_timings             1,9 GB
browser_pageview_events  1,8 GB
ai_api_audit_logs        1,6 GB
incoming_links           1,5 GB
user_auth_token_logs     1,2 GB

Per confronto:

posts                    844 MB

Ho controllato gli intervalli di dati:

topic_views:
2015-04-03 ~ 2026-08-03

incoming_links:
2015-04-09 ~ 2026-08-03

user_auth_token_logs:
2021-08-15 ~ 2026-08-03

ai_api_audit_logs:
2026-02-04 ~ 2026-08-03

browser_pageview_events:
2026-05-28 ~ 2026-08-03

Comprendo che queste tabelle hanno scopi diversi, ma non sono sicuro di quali periodi di conservazione siano considerati ragionevoli per un’istanza Discourse in produzione.

Le mie domande:

1. Per user_auth_token_logs, per quanto tempo solitamente conservate i record?

   • 6 mesi?
   • 1 anno?
   • Più a lungo per audit di sicurezza?

2. Per tabelle come incoming_links, topic_views e post_timings, conservate normalmente tutti i dati storici o rimuovete periodicamente i record più vecchi?

3. Esiste una procedura di pulizia o manutenzione consigliata prima di un aggiornamento importante di PostgreSQL?

Finora, non ho cancellato nulla. Ho eseguito solo:

vacuumdb --analyze discourse

Il mio obiettivo è liberare spazio su disco non necessario prima di aggiornare a PostgreSQL 18, mantenendo al contempo la funzionalità normale di Discourse e le informazioni utili per l’audit.

Apprezzerei qualsiasi raccomandazione o esperienza pratica da parte di chi gestisce siti Discourse self-hosted.

Grazie!

[Ed_S]

È una buona domanda, penso. Ma tieni presente che l’argomento linkato è stato aggiornato e ora indica che serve spazio libero su disco pari a due volte la dimensione del database — cosa che, a quanto pare, hai già.

Nel mio caso, vedo che ho molte immagini Docker non pulite, un file swap di grandi dimensioni, tutti i miei backup e, in un caso, anche 4 GB di file di log.

Quindi, come complemento alla riduzione delle dimensioni del database su disco, si può esaminare anche altro contenuto su disco che può essere ridotto.

[Falco]

@scavin

ai_api_audit_logs 1,6 GB

Puoi controllare il periodo di conservazione di questa tabella tramite le impostazioni del sito.

@scavin

2. Per tabelle come incoming_links, topic_views e post_timings, mantieni normalmente tutti i dati storici o rimuovi periodicamente i record più vecchi?

Queste sono destinate a essere conservate per sempre e sono solitamente le tabelle più grandi nella maggior parte delle istanze, quindi non te ne preoccuperei.