Журнал предзаписи (WAL): принцип

Идея WAL - в порядке записи. Любое изменение данных делается в два приёма:

1. сначала в журнал дописывается запись об изменении (что, где, как);
2. только потом (и не обязательно сразу) меняется сама страница в кеше, а на диск файла данных она попадёт ещё позже.

Ключ - в слове «сначала». Журнальная запись об изменении гарантированно оказывается на диске раньше, чем изменённая страница данных. Отсюда название - запись с опережением, write-ahead.

Почему это спасает. Если сбой случится после записи в журнал, но до записи страницы - не беда: при старте PostgreSQL прочитает журнал и применит изменение к данным заново. Если сбой случится до записи в журнал - значит, транзакция ещё не была подтверждена, и терять нечего. В любом исходе данные согласованы.

Может показаться, что мы пишем всё дважды - и в журнал, и в данные. Но журнал обходится гораздо дешевле по одной причине: он пишется последовательно.

Изменения в большой базе разбросаны по диску: обновили строку здесь, вставили там, тронули индекс в третьем месте. Записывать эти страницы сразу - значит гонять головку диска (или нагружать SSD случайными записями) по всему тому. А журнал - это один поток, который всегда пишется в конец. Последовательная запись на порядки быстрее случайной.

Поэтому WAL позволяет подтвердить транзакцию быстрой последовательной дозаписью в журнал, а медленную случайную запись страниц данных отложить и размазать во времени (этим занимаются bgwriter и контрольная точка). Журнал превращает множество мелких случайных записей в одну последовательную.

Журнал - это непрерывный поток байт. Позицию в нём задаёт LSN (Log Sequence Number) - просто смещение в байтах от начала потока. Это монотонно растущее число; у него даже свой тип - pg_lsn, печатается как 16/B374D848.

LSN - это «время» в мире WAL. У каждой журнальной записи свой LSN, и каждая страница данных помнит LSN последнего изменения, которое в ней отражено (в заголовке страницы - pd_lsn). Это даёт точное правило согласованности: страницу нельзя записать на диск, пока журнал не сброшен хотя бы до её pd_lsn. Иначе на диске оказалась бы страница, изменение которой ещё не зафиксировано в журнале - нарушение write-ahead.

SELECT pg_current_wal_lsn();              -- текущая позиция записи в WAL

SELECT pg_current_wal_lsn() - '0/0';      -- сколько байт WAL уже сгенерировано

Разница двух LSN - это объём журнала между ними в байтах. По ней измеряют темп генерации WAL и лаг репликации. Подробнее - в wal.

Теперь понятно, что физически означает успешный COMMIT. В момент подтверждения транзакции PostgreSQL дописывает в журнал запись о коммите и дожидается, пока журнал будет сброшен на диск (fsync) до этой записи включительно. Только после этого клиент получает «ОК».

Это и есть буква D в ACID - durability. После ответа «закоммичено» данные переживут сбой, даже если страницы в файлах данных ещё не записаны: журнал на диске, а из него всё восстановимо.

У этого ожидания есть рычаг - synchronous_commit:

• on (по умолчанию) - COMMIT ждёт сброса журнала на диск. Полная надёжность;
• off - COMMIT возвращается, не дожидаясь fsync. Быстрее, но при сбое можно потерять несколько последних подтверждённых транзакций (данные при этом остаются согласованными - теряется только хвост).

Это честный компромисс «скорость против гарантии», и включать off можно осознанно для данных, которые не жалко потерять в последние доли секунды.

Журнал - последняя линия обороны данных, поэтому он защищён от тихой порчи. Каждая WAL-запись несёт контрольную сумму (CRC) своего содержимого. При восстановлении PostgreSQL проверяет CRC каждой записи перед тем, как её применить.

Это даёт чёткую границу целого журнала. Если при чтении журнала встречается запись с битой CRC или оборванная на полузаписи (так бывает, если сбой случился прямо во время записи) - PostgreSQL считает, что журнал здесь и кончился. Всё до этой точки целостно и применяется; всё после - отбрасывается как недописанное. Так восстановление никогда не применит «полузапись».

Есть коварная проблема на стыке с железом. Страница PostgreSQL - 8 КБ, а диск (или ОС) пишет блоками поменьше, например по 4 КБ. Если сбой случится прямо во время записи 8-КБ страницы, на диск может попасть её половина: первые 4 КБ новые, вторые - старые. Это «рваная запись» (torn page), и обычная WAL-запись («измени байт X на Y») такую страницу не починит - она опирается на то, что страница целая.

Решение - full-page image (FPI). При первом изменении страницы после каждой контрольной точки PostgreSQL пишет в журнал не дельту, а всю страницу целиком. При восстановлении такая полная копия кладётся поверх возможно рваной страницы - и дальше уже применяются обычные мелкие записи.

За это отвечает параметр full_page_writes (по умолчанию on). Отсюда же - всплеск объёма WAL сразу после контрольной точки: первые изменения каждой страницы тащат за собой по полной копии. Подробнее - в full-page-images.

Подводный камень: отключать full_page_writes почти всегда нельзя. Соблазн есть - FPI заметно раздувают журнал. Но без них рваная запись при сбое означает повреждённую страницу без шансов на восстановление. Отключают их только на хранилищах, которые сами гарантируют атомарную запись страницы целиком (некоторые специализированные ФС и устройства), и только зная это точно.

Физически журнал - это набор файлов-сегментов в каталоге pg_wal/, по умолчанию по 16 МБ каждый. Когда сегмент заполняется, начинается следующий. Старые сегменты, уже не нужные для восстановления и репликации, переиспользуются или удаляются при контрольной точке.

Записывают журнал:

• бэкенды - в буфер WAL в разделяемой памяти (wal_buffers);
• walwriter - фоновый процесс, который регулярно сбрасывает буфер WAL на диск, чтобы бэкендам не приходилось делать это самим;
• на COMMIT при synchronous_commit = on сброс инициирует сам коммитящий бэкенд.

Темп генерации журнала видно в pg_stat_wal:

SELECT wal_records, wal_bytes, wal_fpi FROM pg_stat_wal;

wal_fpi - число full-page images; всплеск после контрольной точки виден именно здесь.

WAL придумали ради восстановления после сбоя, но из одного потока изменений естественно вырастают и другие возможности:

• репликация - тот же поток WAL можно передавать на другой сервер и проигрывать там, поддерживая копию базы (часть VIII);
• восстановление на точку (PITR) - храня архив сегментов WAL, можно восстановить базу на любой момент в прошлом;
• логическое декодирование - из WAL можно извлекать изменения в виде логических событий (вставка/обновление строки), а не физических правок страниц.

Все они опираются на один и тот же журнал - меняется лишь то, сколько в него пишут. Этим управляет wal_level, и о нём - глава 20. А следующая глава - о том, как именно журнал проигрывается при восстановлении и зачем нужны контрольные точки.