Falla la restauración por falta de espacio en disco en la migración debido a 70M eventos de calendario

pfaffman · 9 Febrero, 2026 19:36

Tengo una instalación estándar que está intentando restaurar una base de datos. Está fallando en la migración.


ALTER TABLE
Migrando la base de datos...
EXCEPCIÓN: rake db:migrate
Fallo al migrar la base de datos.
rake abortado!
StandardError: Ha ocurrido un error, este y todas las migraciones posteriores han sido canceladas: (StandardError)

PG::DiskFull: ERROR:  no se pudo escribir en el archivo \"base/pgsql_tmp/pgsql_tmp11009.51\": No queda espacio en el 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'

Hay 90 GB de datos libres en el disco. En el disco de origen, el directorio de postgres es de solo 23 GB.

¿Cómo es que una base de datos de 23 GB falla al restaurarse durante la migración de la base de datos con 90 GB libres?

Origen – Versión del servidor: 3.5.0.beta5-dev (Commit: b16fb6a60b3f1db475cbb91a51b7d4c734370083 — 7 de mayo de 2025)

Versión del servidor de destino: 2026.2.0-latest (Commit: b39866eb8891648a54764755e2e36eb725bd6c73 — Hace 4 días)

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

pfaffman · 11 Febrero, 2026 00:55

-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# # después de eliminar
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 Febrero, 2026 15:27

Después de que la base de datos se restaurara, postgres_data tenía 24G.

Algo en la migración hizo que postgres_data se inflara hasta 91G antes de que el disco se llenara y la restauración fallara. Esto es en una instalación limpia con las versiones de Discourse mostradas anteriormente.

Esto parece ser un error, así que estoy recategorizando. También lo he visto al intentar actualizar. Pensé que para esa actualización una solución sería migrar a un servidor nuevo, pero ahora veo que eso no funcionará.

Supongo que lo siguiente que haré será intentar ver qué consulta está causando esto y/o qué tabla es. No estoy muy seguro de cómo proceder con eso.

sam · 11 Febrero, 2026 23:44

Estoy poniendo esto en soporte, este mensaje viene directo del sistema de archivos, si PG piensa que no tiene espacio, probablemente no tiene espacio porque no se le ha asignado suficiente.

pfaffman · 12 Febrero, 2026 03:06

¿Tiene alguna pista de cómo una base de datos de 24G podría expandirse a 90G durante la migración de la base de datos?

sam · 12 Febrero, 2026 03:39

No estoy seguro… Probablemente ejecutaría ncdu o algo similar y echaría un vistazo cuando ocurrió la situación.

pfaffman · 12 Febrero, 2026 14:20

Usando du y df observé el tamaño de postgres_data mientras crecía de 25g a 90g y el espacio en el disco llegaba a (casi) cero antes de que fallara.

Supongo que necesito encontrar una manera de rastrear qué consulta se está ejecutando la próxima vez.

Lo he visto en al menos dos sitios. Uno con una actualización y otro con una restauración. Ambos tenían más espacio libre que el tamaño de la base de datos para empezar.

Falco · 12 Febrero, 2026 16:02

Un montón de migraciones reescriben tablas enteras, lo que puede usar temporalmente más espacio, y PostgreSQL tampoco devuelve el espacio al sistema de forma agresiva.

¿Ese foro tiene IA con incrustaciones (embeddings) activada?

pfaffman · 12 Febrero, 2026 18:52

Estaba pensando algo así…

Ese parece ser el culpable probable… suspirar. No. Ni siquiera tiene instalado el complemento de IA.

Falco · 12 Febrero, 2026 18:55

Si quieres profundizar, podrías restaurarlo manualmente a un entorno de desarrollo que esté en el commit de mayo de 2025, luego ir al commit actual y ejecutar las migraciones una por una e imprimir el espacio antes y después de cada una — obviamente con un script .

pfaffman · 14 Febrero, 2026 18:06

OK. Estoy restaurando en un sitio de producción. Está migrando.

Aquí hay una consulta que se ha estado ejecutando durante 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)

Eso es de esto:

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

Esto muestra que la migración más reciente es posterior, pero supongo que es porque esa migración es de un complemento que acaba de agregarse; .

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

¡Hay muchos eventos de calendario! ¡69_724_384!

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

Así que supongo que ese es el problema.

. . . pero ¿ni siquiera tienen instalado discourse_calendar en el sitio de origen!?

Pero SÍ tienen ese número de eventos en la tabla de origen calendar_events. . . .

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

Falla la restauración por falta de espacio en disco en la migración debido a 70M eventos de calendario

Origen – Versión del servidor: 3.5.0.beta5-dev (Commit: b16fb6a60b3f1db475cbb91a51b7d4c734370083 — 7 de mayo de 2025)

Versión del servidor de destino: 2026.2.0-latest (Commit: b39866eb8891648a54764755e2e36eb725bd6c73 — Hace 4 días)

Temas relacionados