Il ripristino fallisce per mancanza di spazio su disco durante la migrazione a causa di 70M eventi del calendario

pfaffman · 9 Febbraio 2026, 7:36pm

Ho un’installazione standard che sta tentando di ripristinare un database. Fallisce durante la migrazione.


ALTER TABLE
Migrating the database...
EXCEPTION: rake db:migrate
Failed to migrate database.
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)

PG::DiskFull: ERROR:  could not write to file "base/pgsql_tmp/pgsql_tmp11009.51": No space left on device
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:109:in `exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:109:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/postgresql/database_state
ments.rb:167:in `perform_query'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract/database_stateme
nts.rb:556:in `block (2 levels) in raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:1017:in `block in with_raw_connection'

Ci sono 90 GB di spazio libero sul disco. Sul disco di origine, la directory postgres è solo 23 GB.

Come può un database da 23 GB fallire il ripristino durante la migrazione del database con 90 GB liberi?

Sorgente – Versione del server: 3.5.0.beta5-dev (Commit: b16fb6a60b3f1db475cbb91a51b7d4c734370083 — 7 maggio 2025)

Versione del server di destinazione: 2026.2.0-latest (Commit: b39866eb8891648a54764755e2e36eb725bd6c73 — 4 giorni)

23G     /var/discourse/shared/standalone/postgres_data/

pfaffman · 11 Febbraio 2026, 12:55am

-rw-r--r-- 1 discourse discourse  16G Feb 10 21:13 site-2026-02-10-174058-v20250507013646.sql
-rw-r--r-- 1 discourse discourse 2.9G Feb 10 21:11 site-2026-02-10-174058-v20250507013646.sql.gz

root@forum-data:/shared# # dopo l'eliminazione
root@forum-data:/shared# du -hs postgres_data/; df -h .
24G     postgres_data/
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       154G   87G   68G  56% /shared
....
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       154G  154G  607M 100% /shared
overlay         154G  154G  607M 100% /
91G     postgres_data/
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       154G  154G   82M 100% /shared
overlay         154G  154G   82M 100% /
1.1G    postgres_data/
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       154G   65G   90G  42% /shared
overlay         154G   65G   90G  42% /
1.1G    postgres_data/
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       154G   65G   90G  42% /shared
overlay         154G   65G   90G  42% /
1.1G    postgres_data/
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       154G   65G   90G  42% /shared
overlay         154G   65G   90G  42% /
1.1G    postgres_data/
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       154G   65G   90G  42% /shared
overlay         154G   65G   90G  42% /
1.1G    postgres_data/

pfaffman · 11 Febbraio 2026, 3:27pm

Dopo che il database è stato ripristinato, postgres_data era di 24G.

Qualcosa nella migrazione ha fatto sì che postgres_data salisse a 91G prima che il disco si riempisse e il ripristino fallisse. Questo è su un’installazione pulita con le versioni di Discourse mostrate sopra.

Questo sembra proprio un bug, quindi sto ricategorizzando. L’ho visto anche quando ho provato ad aggiornare. Pensavo che per quell’aggiornamento una soluzione sarebbe stata passare a un nuovo server, ma ora vedo che non funzionerà.

Immagino che la prossima cosa da fare sarà provare a vedere quale query sta causando questo e/o quale tabella sia. Non sono del tutto sicuro di come procedere.

sam · 11 Febbraio 2026, 11:44pm

Sto inserendo questo nel supporto, questo messaggio proviene direttamente dal file system, se PG pensa di non avere spazio, probabilmente non ha spazio perché non ne è stato allocato abbastanza per esso.

pfaffman · 12 Febbraio 2026, 3:06am

Hai qualche suggerimento su come un database da 24G possa espandersi a 90G durante la migrazione del database?

sam · 12 Febbraio 2026, 3:39am

non sono sicuro… probabilmente eseguirei ncdu o qualcosa di simile e darei un’occhiata a quando si è verificata la situazione.

pfaffman · 12 Febbraio 2026, 2:20pm

Usando du e df ho osservato la dimensione di postgres_data crescere da 25g a 90g e lo spazio sul disco arrivare a (quasi) zero prima che fallisse.

Immagino di dover trovare un modo per tracciare quale query è in esecuzione la prossima volta.

L’ho visto su almeno due siti. Uno durante un aggiornamento e uno durante un ripristino. Entrambi avevano più spazio libero della dimensione del database all’inizio.

Falco · 12 Febbraio 2026, 4:02pm

Un mucchio di migrazioni riscrive intere tabelle, il che può temporaneamente utilizzare più spazio, e PostgreSQL non restituisce aggressivamente lo spazio al sistema.

Quel forum ha l’IA con gli embedding abilitati?

pfaffman · 12 Febbraio 2026, 6:52pm

Stavo pensando qualcosa del genere. . .

Sembra una causa probabile. . . . sospiro. No. Non ha nemmeno il plugin IA installato.

Falco · 12 Febbraio 2026, 6:55pm

Se vuoi addentrarti nel tunnel, potresti ripristinarlo manualmente in un ambiente di sviluppo che si trova al commit di maggio 2025, quindi passare al commit corrente ed eseguire le migrazioni una per una e stampare lo spazio prima e dopo ciascuna — ovviamente con uno script .

pfaffman · 14 Febbraio 2026, 6:06pm

OK. Sto ripristinando su un sito di produzione. È in fase di migrazione.

Ecco una query che è in esecuzione da 30 minuti:

discourse=# SELECT pid, usename, state, query, query_start
FROM pg_stat_activity
WHERE state = 'active';
 pid |  usename  | state  |                                                    query                                                     |          query_start
-----+-----------+--------+--------------------------------------------------------------------------------------------------------------+-------------------------------
 519 | postgres  | active | SELECT pid, usename, state, query, query_start                                                              +| 2026-02-14 17:58:35.473337+00
     |           |        | FROM pg_stat_activity                                                                                       +|
     |           |        | WHERE state = 'active';                                                                                      |
 308 | discourse | active | DELETE                                                                                                      +| 2026-02-14 17:26:08.12598+00
     |           |        |   FROM calendar_events ce                                                                                   +|
     |           |        | WHERE                                                                                                       +|
     |           |        |   ce.id IN (SELECT DISTINCT(ce3.id) FROM calendar_events ce2                                                +|
     |           |        |             LEFT JOIN calendar_events ce3 ON ce3.user_id = ce2.user_id AND ce3.description = ce2.description+|
     |           |        |             WHERE ce2.start_date >= (ce3.start_date - INTERVAL '1 days')                                    +|
     |           |        |               AND ce2.start_date <= (ce3.start_date + INTERVAL '1 days')                                    +|
     |           |        |               AND ce2.timezone IS NOT NULL                                                                  +|
     |           |        |               AND ce3.timezone IS NULL                                                                      +|
     |           |        |               AND ce3.id != ce2.id                                                                          +|
     |           |        |               AND ce2.post_id IS NULL                                                                       +|
     |           |        |               AND ce3.post_id IS NULL                                                                       +|
     |           |        |   )                                                                                                         +|
     |           |        |                                                                                                              |
(2 rows)

Questo deriva da questo:

github.com/discourse/discourse

plugins/discourse-calendar/db/migrate/20231124021939_delete_similar_holidays.rb

main

# frozen_string_literal: true

class DeleteSimilarHolidays < ActiveRecord::Migration[7.0]
  def up
    execute <<~SQL
      DELETE
        FROM calendar_events ce
      WHERE
        ce.id IN (SELECT DISTINCT(ce3.id) FROM calendar_events ce2
                  LEFT JOIN calendar_events ce3 ON ce3.user_id = ce2.user_id AND ce3.description = ce2.description
                  WHERE ce2.start_date >= (ce3.start_date - INTERVAL '1 days')
                    AND ce2.start_date <= (ce3.start_date + INTERVAL '1 days')
                    AND ce2.timezone IS NOT NULL
                    AND ce3.timezone IS NULL
                    AND ce3.id != ce2.id
                    AND ce2.post_id IS NULL
                    AND ce3.post_id IS NULL
        )
    SQL
  end

This file has been truncated. show original

Questo mostra che l’ultima migrazione è successiva, ma immagino sia perché quella migrazione proviene da un plugin che è stato appena aggiunto;.

discourse=# SELECT version FROM schema_migrations ORDER BY version DESC LIMIT 1;
    version
----------------
 20250507013646
(1 row)

Ci sono molti eventi del calendario!!! 69_724_384!

discourse=# select count(*) from calendar_events;
  count
----------
 69724384
(1 row)

Quindi immagino che questo sia il problema.

. . . ma non hanno nemmeno installato discourse_calendar sul sito di origine!?

Ma hanno quel numero di eventi nella tabella calendar_events sulla tabella di origine. . . .

Argomento		Risposte	Visualizzazioni
Restore Failing - Check Free Disk Space Installation server-resources	11	1660	Gennaio 19, 2021
Problem with restore Discourse from backup (3.4, quite large DB) Support	18	259	Gennaio 14, 2025
Testing Restore - not working Installation backups	4	403	Agosto 22, 2023
Database issues migrating form old version 20150822141540 Installation	14	998	Ottobre 22, 2022
Restore to New Host Support	13	593	Gennaio 15, 2026

Il ripristino fallisce per mancanza di spazio su disco durante la migrazione a causa di 70M eventi del calendario

Sorgente – Versione del server: 3.5.0.beta5-dev (Commit: b16fb6a60b3f1db475cbb91a51b7d4c734370083 — 7 maggio 2025)

Versione del server di destinazione: 2026.2.0-latest (Commit: b39866eb8891648a54764755e2e36eb725bd6c73 — 4 giorni)

Argomenti correlati