# Восстановление завершается ошибкой из-за нехватки места на диске при миграции, вызванной 70 млн событий календаря
**URL:** https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584
**Category:** Support
**Tags:** events
**Created:** [09.Февраль.2026 19:36:22 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584 "2026-02-09T19:36:22Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [09.Февраль.2026 19:36:22 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/1 "2026-02-09T19:36:22Z")
У меня стандартная установка, которая пытается восстановить базу данных. Ошибка возникает на этапе миграции.
```plaintext
ALTER TABLE
Миграция базы данных...
EXCEPTION: rake db:migrate
Не удалось выполнить миграцию базы данных.
rake aborted!
StandardError: Произошла ошибка, эта и все последующие миграции отменены: (StandardError)
PG::DiskFull: ERROR: не удалось записать в файл "base/pgsql_tmp/pgsql_tmp11009.51": на устройстве не осталось места
/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_statements.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_statements.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'
```
На диске свободно 90 ГБ. На исходном диске каталог postgres занимает всего 23 ГБ.
Как может база данных размером 23 ГБ не восстановиться во время миграции, если свободно 90 ГБ?
### Источник – Версия сервера: 3.5.0.beta5-dev (Коммит: [b16fb6a60b3f1db475cbb91a51b7d4c734370083](https://dashboard.literatecomputing.com/pfaffmanager/servers/b16fb6a60b3f1db475cbb91a51b7d4c734370083) — 7 мая 2025 г.)
### Версия сервера назначения: 2026.2.0-latest (Коммит: [b39866eb8891648a54764755e2e36eb725bd6c73](https://dashboard.literatecomputing.com/pfaffmanager/servers/b39866eb8891648a54764755e2e36eb725bd6c73) — 4 дня назад)
```plaintext
23G /var/discourse/shared/standalone/postgres_data/
```
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [11.Февраль.2026 00:55:45 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/2 "2026-02-11T00:55:45Z")
```bash
-rw-r--r-- 1 discourse discourse 16G 10 фев 21:13 site-2026-02-10-174058-v20250507013646.sql
-rw-r--r-- 1 discourse discourse 2.9G 10 фев 21:11 site-2026-02-10-174058-v20250507013646.sql.gz
```
```bash
root@forum-data:/shared# # после удаления
root@forum-data:/shared# du -hs postgres_data/; df -h .
24G postgres_data/
Файловая система Размер Использовано Свободно Исполь% Смонтировано на
/dev/vda1 154G 87G 68G 56% /shared
....
Файловая система Размер Использовано Свободно Исполь% Смонтировано на
/dev/vda1 154G 154G 607M 100% /shared
overlay 154G 154G 607M 100% /
91G postgres_data/
Файловая система Размер Использовано Свободно Исполь% Смонтировано на
/dev/vda1 154G 154G 82M 100% /shared
overlay 154G 154G 82M 100% /
1.1G postgres_data/
Файловая система Размер Использовано Свободно Исполь% Смонтировано на
/dev/vda1 154G 65G 90G 42% /shared
overlay 154G 65G 90G 42% /
1.1G postgres_data/
Файловая система Размер Использовано Свободно Исполь% Смонтировано на
/dev/vda1 154G 65G 90G 42% /shared
overlay 154G 65G 90G 42% /
1.1G postgres_data/
Файловая система Размер Использовано Свободно Исполь% Смонтировано на
/dev/vda1 154G 65G 90G 42% /shared
overlay 154G 65G 90G 42% /
1.1G postgres_data/
```
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [11.Февраль.2026 15:27:09 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/3 "2026-02-11T15:27:09Z")
После восстановления базы данных размер `postgres_data` составлял 24 ГБ.
В ходе миграции `postgres_data` увеличился до 91 ГБ, что привело к заполнению диска и сбою восстановления. Это произошло на чистой установке с версиями Discourse, указанными выше.
Похоже, это ошибка, поэтому я меняю категорию. Я также сталкивался с этим при попытке обновления. Раньше я думал, что решением для обновления будет перенос на новый сервер, но теперь вижу, что это не сработает.
Следующим шагом, вероятно, будет попытка выяснить, какой запрос или таблица вызывает эту проблему. Я не совсем уверен, как это сделать.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [11.Февраль.2026 23:44:16 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/4 "2026-02-11T23:44:16Z")
Я размещаю это в службу поддержки. Это сообщение приходит напрямую из файловой системы. Если PostgreSQL считает, что у него нет места, то, вероятно, места действительно нет, потому что для него выделено недостаточно пространства.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12.Февраль.2026 03:06:31 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/5 "2026-02-12T03:06:31Z")
У вас есть какие-либо подсказки, как база данных размером 24 ГБ могла увеличиться до 90 ГБ во время миграции базы данных?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [12.Февраль.2026 03:39:02 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/6 "2026-02-12T03:39:02Z")
Не уверен… Я бы, вероятно, запустил ncdu или что-то подобное и посмотрел, что произошло в этой ситуации.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12.Февраль.2026 14:20:30 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/7 "2026-02-12T14:20:30Z")
Используя `du` и `df`, я отслеживал размер каталога postgres\_data, который вырос с 25 ГБ до 90 ГБ, и наблюдал, как свободное место на диске практически исчерпалось перед сбоем.
Полагаю, мне нужно найти способ отслеживать выполнение запроса в следующий раз.
Я сталкивался с этим как минимум на двух сайтах: один при обновлении, другой при восстановлении. В обоих случаях изначально свободного места было больше, чем размер базы данных.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [12.Февраль.2026 16:02:54 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/8 "2026-02-12T16:02:54Z")
Множество миграций полностью переписывают таблицы, что может временно занимать больше места, а PostgreSQL не слишком агрессивно возвращает это место системе.
Есть ли в том форуме AI с включёнными эмбеддингами?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12.Февраль.2026 18:52:26 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/9 "2026-02-12T18:52:26Z")
> [@Falco](#):
>
> Многие миграции переписывают целые таблицы, что может временно занимать больше места, а PostgreSQL не слишком агрессивно возвращает свободное место системе.
Я как раз думал о чём-то подобном. . .
> [@Falco](#):
>
> А на этом форуме включены AI с эмбеддингами?
Кажется, это наиболее вероятная причина. . . . вздох. Нет. Установлен даже не плагин AI.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [12.Февраль.2026 18:55:07 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/10 "2026-02-12T18:55:07Z")
Если вы хотите углубиться в детали, можно вручную восстановить окружение на версию с коммита от мая 2025 года, затем перейти к текущему коммиту и выполнять миграции по одной, выводя размер до и после каждой — разумеется, с помощью скрипта 😛.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [14.Февраль.2026 18:06:43 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/11 "2026-02-14T18:06:43Z")
OK. Я выполняю восстановление на продакшн-сайте. Идет миграция.
Вот запрос, который выполняется уже 30 минут:
```plaintext
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)
```
Это из этого файла:
>
Здесь видно, что последняя миграция новее, но я полагаю, что это потому, что эта миграция относится к плагину, который был добавлен только что.
```plaintext
discourse=# SELECT version FROM schema_migrations ORDER BY version DESC LIMIT 1;
version
----------------
20250507013646
(1 row)
```
Событий календаря очень много!!! 69 724 384!
```plaintext
discourse=# select count(*) from calendar_events;
count
----------
69724384
(1 row)
```
Так что, похоже, это и есть проблема.
… но на исходном сайте плагин discourse\_calendar даже не установлен!?
Но в таблице calendar\_events на исходном сайте как раз такое количество событий…
Но в post\_custom\_fields есть только 4 записи, связанные с событием календаря?.
Так что есть много событий, не привязанных к теме или посту. Обычные праздники, такие как Рождество, Новый год, День подарков.
### Вот решение
```plaintext
delete from calendar_events where topic_id=0 and post_id is null and post_number is null;
```
После этого осталось 99 событий.
Может быть, SiteSetting.delete\_expired\_event\_posts\_after был установлен в 0, и хотя плагин толком не использовался, он создал все эти события?
И да! `SiteSetting.delete_expired_event_posts_after` установлен в `-1`.
О, но -1 — это значение по умолчанию. Так что, возможно, это и есть проблема?
Нет. Это касается **ПОСТОВ** событий. Я не совсем понимаю, откуда взялось 70 миллионов событий.
```plaintext
https://github.com/discourse/discourse/blob/main/plugins/discourse-calendar/config/settings.yml#L11-L13
```
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [16.Март.2026 18:07:30 UTC](https://meta.discourse.org/t/restore-fails-due-to-disk-space-on-migration-because-of-70m-calendar-events/395584/12 "2026-03-16T18:07:30Z")
Эта тема была автоматически закрыта через 30 дней после последнего ответа. Новые ответы больше не принимаются.