Контрольные точки и восстановление

Вспомним зазор между памятью и диском. Изменённые страницы копятся в буферном кеше «грязными», на диск файлов данных попадают не сразу. Журнал помнит все изменения, но он растёт бесконечно.

Контрольная точка ставит границу. В этот момент PostgreSQL сбрасывает на диск все грязные буферы, накопленные к данному моменту, и записывает в служебный файл pg_control отметку: «до вот этой позиции журнала (redo point) все изменения уже в файлах данных».

После этого весь журнал до redo point больше не нужен для восстановления - его можно переиспользовать или удалить. А восстановление, случись оно, начнётся не с начала времён, а с последней контрольной точки. Чем чаще контрольные точки, тем короче восстановление - но тем больше работы по записи в обычное время.

Тонкость: контрольная точка не мгновенна. Пока она сбрасывает грязные буферы (это может занять минуты), база продолжает работать и писать новый журнал. Поэтому redo point - это позиция журнала на момент начала контрольной точки, а не её завершения.

Логика такая: всё, что было грязным к началу контрольной точки, она гарантированно запишет. Значит, восстановление, начатое с redo point, увидит в журнале все изменения, которые на тот момент ещё не были в файлах данных, и доиграет их. Изменения до redo point уже на диске - их проигрывать не нужно.

pg_control хранит redo point последней завершённой контрольной точки. Именно его читает PostgreSQL при старте, чтобы понять, с какого места проигрывать журнал.

Теперь сложим процедуру. Сервер упал - kill -9, отключили питание, паника ядра. При следующем старте PostgreSQL видит, что был остановлен некорректно, и запускает crash recovery:

По шагам:

1. читаем redo point из pg_control;
2. идём по журналу от redo point вперёд, применяя каждую запись к страницам (это фаза redo);
3. full-page images по пути чинят возможные рваные страницы, дельты накатывают остальные изменения;
4. доходим до места, где журнал обрывается (битая или неполная CRC) - это конец доступного журнала;
5. база открыта.

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

Естественный вопрос: redo проигрывает весь журнал, включая изменения транзакций, которые на момент сбоя не были закоммичены. Разве они не «оживут»?

Нет, и вот почему. Redo действительно накатывает на страницы и изменения незакоммиченных транзакций - физически они появляются в данных. Но видимость в PostgreSQL решает не наличие версии, а статус её транзакции в clog. Транзакция, не успевшая закоммититься до сбоя, в clog так и осталась незавершённой - а значит, по правилам видимости её версии не видны никому. Фактически она откачена.

Получается красиво: redo не разбирает, кто закоммичен, а кто нет - он тупо восстанавливает физическое состояние. А логику «видно/не видно» берёт на себя MVCC поверх clog. Поэтому после восстановления закоммиченные изменения на месте, а незакоммиченные невидимы - ровно как и положено.

Контрольную точку запускают два повода, что наступит раньше:

• по времени - checkpoint_timeout (по умолчанию 5 минут);
• по объёму журнала - когда с прошлой контрольной точки накопилось журнала больше max_wal_size (по умолчанию 1 ГБ).

Плюс контрольную точку можно вызвать вручную командой CHECKPOINT или косвенно - например, она случается перед остановкой сервера.

max_wal_size - это не жёсткий лимит на размер pg_wal/, а порог, при котором инициируется контрольная точка. Если база пишет быстрее, чем контрольные точки успевают, журнал может временно превысить этот размер. Поэтому на нагруженных базах max_wal_size поднимают, чтобы контрольные точки случались по таймеру, а не каждые несколько секунд по объёму.

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

Чтобы сгладить всплеск, PostgreSQL растягивает запись грязных буферов во времени. Управляет этим checkpoint_completion_target (по умолчанию 0.9): контрольная точка старается размазать запись на 90% интервала до следующей. Вместо шквала - ровный фоновый поток записи.

Это объясняет, почему ручной CHECKPOINT ощущается как нагрузка, а штатные контрольные точки - почти нет: ручная торопится, штатная не спешит. На пиковых базах баланс между checkpoint_timeout, max_wal_size и checkpoint_completion_target - один из главных рычагов сглаживания нагрузки на диск. Разбор и метрики - в checkpoint.

В PostgreSQL 17 статистику по контрольным точкам вынесли в отдельный вид pg_stat_checkpointer (раньше она жила в pg_stat_bgwriter):

SELECT num_timed, num_requested, buffers_written

FROM pg_stat_checkpointer;

• num_timed - контрольные точки по таймеру (checkpoint_timeout);
• num_requested - по объёму журнала или вручную;
• buffers_written - сколько грязных буферов они записали.

Здоровый признак - когда num_timed заметно больше num_requested: значит, контрольные точки случаются спокойно по расписанию, а не авралом из-за переполнения журнала. Перекос в сторону num_requested

• сигнал поднять max_wal_size. При log_checkpoints = on каждая контрольная точка ещё и пишет в лог сервера подробности.

Мы собрали полный цикл надёжности одиночного сервера: изменения идут в журнал (write-ahead), копятся грязными в кеше, периодически сбрасываются контрольной точкой, а после сбоя redo доигрывает журнал от последней контрольной точки. Закоммиченное переживает сбой, незакоммиченное откатывается через clog.

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