Использование дискового пространства
На дисках кластера PostgreSQL хранятся:
- временные файлы;
- файлы данных;
- журналы транзакций (WAL);
- слоты логической репликации;
- логи СУБД;
- системные файлы, необходимые для функционирования PostgreSQL.
Вы можете следить за объемом используемого дискового пространства.
Когда объем используемого дискового пространства растет, вы можете проверить:
Если диск кластера будет заполнен на 80%, уведомление появится в панели управления и будет отправлено на электронную почту Владельца аккаунта и тех пользователей, которые подписаны на категорию уведомлений Услуги и сервисы.
Если диск кластера будет заполнен на 95% и более, кластер перейдет в статус DISK_FULL и будет работать только на чтение. Чтобы кластер работал на чтение и запись, очистите диск или масштабируйте кластер и выберите конфигурацию с бóльшим размером диска.
Посмотреть размер временных файлов
Временные файлы могут использоваться для сортировки, хеширования и временного хранения результатов запросов. Чтобы посмотреть общий размер временных файлов в базе данных, используйте SQL-запрос к представлению pg_stat_database:
SELECT datname, temp_files AS "Temporary files", temp_bytes AS "Size of temporary files"
FROM pg_stat_database;
Пример вывода:
datname | temp_files | temp_bytes
--------+--------------+----------------
mydb | 2 | 16384
postgres| 1 | 8192
Здесь:
datname— имя базы данных;temp_files— количество временных файлов в этой базе данных;temp_bytes— размер временных файлов в байтах.
В полях temp_files и temp_bytes учитываются все временные файлы с момента создания кластера. Данные сбрасываются только после восстановления из бэкапа или после аварийного завершения работы. Используйте значения этих полей, чтобы следить за изменением общего размера временных файлов.
Размер временных таблиц, создаваемых конкретным запросом, можно получить с помощью команды EXPLAIN ANALYZE.
Проверить потребителей слотов логической репликации
Слоты логической репликации используются для постоянной репликации данных из одной базы в другую. У слотов логической репликации всегда должен быть потребитель. Если потребителя нет, то размер файлов будет расти.
Подробнее об управлении слотами логической репликации в статье Subscription документации PostgreSQL.
Чтобы проверить, есть ли у слотов логической репликации потребители, отправьте SQL-запрос к представлению pg_replication_slots:
SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS replicationSlotLag,active
FROM pg_replication_slots;
Пример вывода:
slot_name | replicationslotlag | active
-----------------+--------------------+--------
myslot1 | 129 GB | f
myslot2 | 704 MB | t
myslot3 | 624 MB | t
Здесь:
slot_name— имя слота логической репликации;replicationslotlag— размер WAL-файлов, которые не будут автоматически удаляться при контрольных точках и которые потребители слота логической репликации могут использовать;active— булево значение показывает, используется ли слот логической репликации:f— у слота нет потребителя;t— у слота есть потребитель.
Если у вас версия PostgreSQL 13 и выше, вы можете ограничить максимальный размер хранимых WAL-файлов с помощью параметра max_slot_wal_keep_size. Учтите, что при использовании этого параметра журнал транзакций может быть удален раньше, чем потребитель прочитает изменения из слота логической репликации.
«Мертвые» кортежи
Когда вы обновляете строки в таблице (UPDATE) или удаляете их (DELETE), кортежи фактически не удаляются с диска, а создаются их новые версии. Старые версии кортежей будут называться «мертвыми»(dead tuples). Такое версионирование необходимо для реализации процесса MVCC (Multi-Version Concurrency Control). Несмотря на то, что строки изменены в одной транзакции, другие активные транзакции могут продолжать видеть старую версию строк. «Мертвые» кортежи могут быть удалены, только когда все активные транзакции будут закрыты.
«Мертвые» кортежи также будут образовываться на реплике, если вы используете логическую репликацию.
Проверить «мертвые» кортежи
Если «мертвых» кортежей много, то они могут занимать значительный объем дискового пространства. Чтобы проверить количество «мертвых» кортежей, используйте представление pg_stat_all_tables.
Пример SQL-запроса к представлению pg_stat_all_tables:
SELECT * FROM pg_stat_all_tables WHERE relname='test';
Пример вывода:
-[ RECORD 1 ]----------+------------------------------
relid | 16395
schemaname | public
relname | test
seq_scan | 3
seq_tup_read | 5280041
idx_scan |
idx_tup_fetch |
n_tup_ins | 2000000
n_tup_upd | 0
n_tup_del | 3639911
n_tup_hot_upd | 0
n_live_tup | 1635941
n_dead_tup | 1999952
n_mod_since_analyze | 3999952
last_vacuum |
last_autovacuum | 2023-02-16 04:49:52.399546+00
last_analyze | 2023-02-09 09:44:56.208889+00
last_autoanalyze | 2023-02-16 04:50:22.581935+00
vacuum_count | 0
autovacuum_count | 1
analyze_count | 1
autoanalyze_count | 1
Здесь n_dead_tup — количество «мертвых» кортежей.
Удалить «мертвые» кортежи
Для удаления «мертвых» кортежей используйте операцию VACUUM или настройте AUTOVACUUM. Эти операции удаляют неиспользуемые версии строк в таблицах и индексах и помечают пространство свободным для дальнейшего использования. Однако это дисковое пространство не возвращается операционной систем е, кроме особого случая, когда полностью освобождаются одна или несколько страниц в конце таблицы и можно получить исключительную блокировку таблицы. Подробнее об операциях VACUUM и AUTOVACUUM в статье Routine Vacuuming документации PostgreSQL.
Очистить диск
Откройте транзакцию transaction_read_only = no и удалите ненужные данные с помощью одного из запросов:
-
DROP TABLE— удаляет структуру (данные, привилегии, индексы, constraints, триггеры). Используйте при полном удалении таблицы с данными и структурой:BEGIN;
SET transaction_read_only = no;
DROP TABLE table_name;
COMMIT; -
TRUNCATE TABLE— удаляет содержимое таблицы, при этом структура сохраняется. Работает быстрееDROP TABLE. Используйте при удалении всех строк таблицы с сохранением структуры таблицы:BEGIN;
SET transaction_read_only = no;
TRUNCATE TABLE table_name;
COMMIT; -
DELETE— используйте для удаления определенных строк.
Мы не рекомендуем использовать запрос DELETE FROM table WHERE ... для очистки диска. Этот запрос может создавать выборки больших размеров на больших таблицах и располагать их на диске. Оставшееся свободное место на диске может полностью закончиться, это приведет к проблемам с PostgreSQL и необходимости восстанавливать его работу вручную.