WAL в PostgreSQL: журнал предзаписи, LSN и восстановление

WAL (Write-Ahead Log) — журнал предзаписи PostgreSQL. Главное правило: запись WAL должна попасть в надёжное хранилище раньше соответствующей изменённой страницы данных. Благодаря этому после сбоя сервер может повторить изменения из журнала.

От INSERT до восстановления

Изменения страниц выполняются в памяти; записи журнала формируются в буферах WAL.
При обычной синхронной фиксации сервер ожидает сохранения необходимых записей WAL, включая запись COMMIT. Все изменённые страницы таблиц при этом сбрасывать не требуется.
Страницы записываются позже. После сбоя восстановление REDO воспроизводит нужные записи WAL.

Нельзя заменять это правило утверждением «каждая запись мгновенно попадает на диск». Настройки synchronous_commit и fsync влияют на гарантии. REDO также не означает, что PostgreSQL отменяет незавершённые транзакции обратными SQL-командами.

WAL, LSN и checkpoint

Понятие	Назначение
WAL	Последовательный журнал изменений
LSN	Позиция в журнале; тип PostgreSQL — pg_lsn
Checkpoint	Контрольная точка, ограничивающая объём работы при восстановлении
pg_wal	Каталог сегментов WAL внутри каталога данных

При включённом full_page_writes первое изменение страницы после контрольной точки сопровождается полным образом страницы в WAL. Он помогает восстановиться после частичной записи страницы. Более частые контрольные точки могут увеличивать этот объём.

Как посмотреть позицию и объём WAL

На основном сервере выполните диагностические запросы. Доступ к статистике может потребовать дополнительных прав:

SELECT pg_current_wal_lsn();
SELECT wal_records, wal_fpi, wal_bytes, stats_reset
FROM pg_stat_wal;
SELECT slot_name, slot_type, active, restart_lsn
FROM pg_replication_slots;

Счётчики pg_stat_wal накопительные: для скорости роста сравнивайте два замера с интервалом и проверяйте stats_reset. Позиция LSN не является датой. Наличие неактивного слота — повод разобраться с потребителем, а не автоматически удалить слот.

Почему растёт pg_wal

Генерируется много изменений, например при массовой загрузке.
Архивирование не успевает или завершается ошибкой.
Слот репликации удерживает сегменты для отставшего потребителя.
Параметры хранения и контрольных точек не соответствуют нагрузке.

Не удаляйте файлы из pg_wal вручную. Сначала проверьте архиватор, слоты и репликацию. max_wal_size не является жёстким ограничением каталога.

WAL не заменяет резервную копию

Для PITR нужна базовая физическая копия и непрерывная последовательность архивных WAL до выбранного момента. Поэтому изменения после бэкапа могут быть восстановлены — если необходимые сегменты сохранены. Репликация решает другую задачу: ошибочное изменение может попасть и на реплику.

Проверку восстановления и причины роста журнала можно обсудить в рамках поддержки баз данных. Последовательное изучение устройства СУБД — в курсе по PostgreSQL.

Документация

← Предыдущая статья

Сбрасывание грязных страниц PostgerSQL

Следующая статья →

Журнал транзакций и файлы сегмента WAL PostgreSQL