Ich habe eine Standardinstallation, die versucht, eine Datenbank wiederherzustellen. Die Migration schlägt fehl.
ALTER TABLE
Datenbank wird migriert...
EXCEPTION: rake db:migrate
Datenbankmigration fehlgeschlagen.
rake abgebrochen!
StandardError: Ein Fehler ist aufgetreten, diese und alle späteren Migrationen wurden abgebrochen: (StandardError)
PG::DiskFull: ERROR: konnte nicht in Datei „base/pgsql_tmp/pgsql_tmp11009.51“ schreiben: Kein Speicherplatz mehr auf dem Gerät
/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'
Auf der Festplatte sind noch 90 GB frei. Auf der Quellfestplatte ist das Postgres-Verzeichnis nur 23 GB groß.
Wie kann eine 23 GB große Datenbank bei der Datenbankmigration fehlschlagen, wenn noch 90 GB frei sind?
Nachdem die Datenbank wiederhergestellt war, betrug postgres_data 24G.
Etwas in der Migration ließ postgres_data auf 91G aufblähen, bevor die Festplatte voll war und die Wiederherstellung fehlschlug. Dies geschieht bei einer sauberen Installation mit den oben gezeigten Discourse-Versionen.
Das scheint ein Fehler zu sein, daher kategorisiere ich neu. Ich habe dies auch gesehen, als ich versuchte, ein Upgrade durchzuführen. Ich dachte bei diesem Upgrade, dass eine Lösung darin bestehen würde, auf einen neuen Server umzuziehen, aber jetzt sehe ich, dass das nicht funktionieren wird.
Ich denke, das Nächste, was ich tun werde, ist zu versuchen herauszufinden, welche Abfrage dies verursacht und/oder welche Tabelle es ist. Ich bin mir nicht ganz sicher, wie ich das angehen soll.
Ich gebe dies an den Support weiter, diese Meldung kommt direkt vom Dateisystem. Wenn PG denkt, es habe keinen Speicherplatz, hat es wahrscheinlich keinen, weil nicht genug dafür reserviert wurde.
Mit du und df habe ich beobachtet, wie die Größe von postgres_data von 25 GB auf 90 GB anwuchs und der Speicherplatz auf der Festplatte (nahezu) Null wurde, bevor es fehlschlug.
Ich schätze, ich muss herausfinden, wie ich das nächste Mal verfolgen kann, welche Abfrage läuft.
Ich habe dies auf mindestens zwei Websites gesehen. Eine bei einem Upgrade und eine bei einer Wiederherstellung. Beide hatten zu Beginn mehr freien Speicherplatz als die Größe der Datenbank.
Eine Reihe von Migrationen schreibt ganze Tabellen neu, was vorübergehend mehr Speicherplatz beanspruchen kann, und PostgreSQL gibt den Speicherplatz nicht aggressiv an das System zurück.
Wenn Sie tief in die Materie eintauchen möchten, könnten Sie es manuell auf eine Entwicklungsumgebung wiederherstellen, die sich beim Commit vom Mai 2025 befindet, dann zum aktuellen Commit gehen und die Migrationen eine nach der anderen ausführen und den Platz davor und danach jeweils ausgeben — natürlich mit einem Skript .
OK. Ich führe eine Wiederherstellung auf einer Produktionsseite durch. Sie wird migriert.
Hier ist eine Abfrage, die seit 30 Minuten läuft:
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)
Das stammt von hier:
Das zeigt, dass die neueste Migration später ist, aber ich nehme an, das liegt daran, dass diese Migration von einem Plugin stammt, das gerade hinzugefügt wurde;.
discourse=# SELECT version FROM schema_migrations ORDER BY version DESC LIMIT 1;
version
----------------
20250507013646
(1 row)
Es gibt eine Menge Kalenderereignisse!!! 69.724.384!
discourse=# select count(*) from calendar_events;
count
----------
69724384
(1 row)
Also, ich denke, das ist das Problem.
. . . aber sie haben nicht einmal discourse_calendar auf der Quellseite installiert!?
Aber sie haben diese Anzahl von Ereignissen in der Tabelle calendar_events auf der Quellseite. . . .
.