Restauração falha devido a espaço em disco na migração por causa de 70M eventos de calendário

pfaffman · Fevereiro 9, 2026, 7:36pm

Estou com uma instalação padrão que está tentando restaurar um banco de dados. Está falhando na migração.


ALTER TABLE
Migrando o banco de dados...
EXCEPTION: rake db:migrate
Falha ao migrar o banco de dados.
rake abortado!
StandardError: Ocorreu um erro, esta e todas as migrações posteriores foram canceladas: (StandardError)

PG::DiskFull: ERRO:  não foi possível escrever no arquivo "base/pgsql_tmp/pgsql_tmp11009.51": Sem espaço livre no dispositivo
/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'

Há 90GB de dados livres no disco. No disco de origem, o diretório postgres tem apenas 23GB.

Como um banco de dados de 23GB está falhando ao restaurar durante a migração do banco de dados com 90GB livres?

Origem – Versão do Servidor: 3.5.0.beta5-dev (Commit: b16fb6a60b3f1db475cbb91a51b7d4c734370083 — 7 de maio de 2025)

Versão do Servidor de Destino: 2026.2.0-latest (Commit: b39866eb8891648a54764755e2e36eb725bd6c73 — 4 dias atrás)

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

pfaffman · Fevereiro 11, 2026, 12:55am

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

root@forum-data:/shared# # após a exclusão
root@forum-data:/shared# du -hs postgres_data/; df -h .
24G     postgres_data/
Sistema de arquivos Tamanho Usado Disp Uso% Montado em
/dev/vda1       154G   87G   68G  56% /shared
....
Sistema de arquivos Tamanho Usado Disp Uso% Montado em
/dev/vda1       154G  154G  607M 100% /shared
overlay         154G  154G  607M 100% /
91G     postgres_data/
Sistema de arquivos Tamanho Usado Disp Uso% Montado em
/dev/vda1       154G  154G   82M 100% /shared
overlay         154G  154G   82M 100% /
1.1G    postgres_data/
Sistema de arquivos Tamanho Usado Disp Uso% Montado em
/dev/vda1       154G   65G   90G  42% /shared
overlay         154G   65G   90G  42% /
1.1G    postgres_data/
Sistema de arquivos Tamanho Usado Disp Uso% Montado em
/dev/vda1       154G   65G   90G  42% /shared
overlay         154G   65G   90G  42% /
1.1G    postgres_data/
Sistema de arquivos Tamanho Usado Disp Uso% Montado em
/dev/vda1       154G   65G   90G  42% /shared
overlay         154G   65G   90G  42% /
1.1G    postgres_data/
Sistema de arquivos Tamanho Usado Disp Uso% Montado em
/dev/vda1       154G   65G   90G  42% /shared
overlay         154G   65G   90G  42% /
1.1G    postgres_data/

pfaffman · Fevereiro 11, 2026, 3:27pm

Após a restauração do banco de dados, postgres_data estava com 24G.

Algo na migração fez com que postgres_data inflasse para 91G antes que o disco ficasse cheio e a restauração falhasse. Isso ocorre em uma instalação limpa com as versões do Discourse mostradas acima.

Isso parece ser um bug, então estou recategorizando. Eu também vi isso ao tentar atualizar. Eu pensei que para aquela atualização uma solução seria migrar para um novo servidor, mas agora percebo que isso não funcionará.

Acho que o próximo passo será tentar descobrir qual consulta está causando isso e/ou qual tabela é. Não tenho bem certeza de como fazer isso.

sam · Fevereiro 11, 2026, 11:44pm

Estou colocando isto no suporte, esta mensagem está vindo diretamente do sistema de arquivos, se o PG acha que não tem espaço, provavelmente não tem espaço porque não foi alocado o suficiente para ele.

pfaffman · Fevereiro 12, 2026, 3:06am

Você tem alguma dica de como um banco de dados de 24G pode expandir para 90G durante a migração do banco de dados?

sam · Fevereiro 12, 2026, 3:39am

não tenho certeza.. Eu provavelmente executaria o ncdu ou algo assim e daria uma olhada quando a situação acontecesse.

pfaffman · Fevereiro 12, 2026, 2:20pm

Usando du e df, observei o tamanho de postgres_data crescer de 25g para 90g e o espaço no disco ir para (quase) zero antes de falhar.

Acho que preciso encontrar uma maneira de rastrear qual consulta está sendo executada da próxima vez.

Eu vi isso em pelo menos dois sites. Um durante uma atualização e outro durante uma restauração. Ambos tinham mais espaço livre do que o tamanho do banco de dados para começar.

Falco · Fevereiro 12, 2026, 4:02pm

Um monte de migrações reescreve tabelas inteiras, o que pode usar temporariamente mais espaço, e o PostgreSQL também não devolve espaço agressivamente ao sistema.

Esse fórum tem IA com embeddings ativados?

pfaffman · Fevereiro 12, 2026, 6:52pm

Eu estava pensando em algo assim…

Esse parece ser o culpado provável… suspiro. Não. Ele nem sequer tem o plugin de IA instalado.

Falco · Fevereiro 12, 2026, 6:55pm

Se você quiser se aprofundar, você poderia restaurá-lo manualmente para um ambiente de desenvolvimento que esteja no commit de maio de 2025, depois ir para o commit atual e executar as migrações uma por uma e imprimir o espaço antes e depois de cada uma — obviamente com um script .

pfaffman · Fevereiro 14, 2026, 6:06pm

OK. Estou restaurando em um site de produção. Está migrando.

Aqui está uma consulta que está sendo executada há 30 minutos:

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)

Isso é de:

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

Isso mostra que a migração mais recente é posterior, mas acho que é porque essa migração é de um plugin que acabou de ser adicionado;.

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

Há muitos eventos de calendário!!! 69_724_384!

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

Então, acho que esse é o problema.

. . . mas eles nem sequer têm o discourse_calendar instalado no site de origem!?

Mas eles TÊM esse número de eventos na tabela calendar_events na tabela de origem. . . .

Tópico		Respostas	Visualizações
Restore Failing - Check Free Disk Space Installation server-resources	11	1660	19 de Janeiro de 2021
Problem with restore Discourse from backup (3.4, quite large DB) Support	18	259	14 de Janeiro de 2025
Testing Restore - not working Installation backups	4	403	22 de Agosto de 2023
Database issues migrating form old version 20150822141540 Installation	14	998	22 de Outubro de 2022
Restore to New Host Support	13	593	15 de Janeiro de 2026

Restauração falha devido a espaço em disco na migração por causa de 70M eventos de calendário

Origem – Versão do Servidor: 3.5.0.beta5-dev (Commit: b16fb6a60b3f1db475cbb91a51b7d4c734370083 — 7 de maio de 2025)

Versão do Servidor de Destino: 2026.2.0-latest (Commit: b39866eb8891648a54764755e2e36eb725bd6c73 — 4 dias atrás)

Tópicos relacionados