WAL и долговечность

Упреждающая запись: сначала лог, потом страница

Прежде чем решать, стоит ли переключить synchronous_commit, нужно понять, что он контролирует — потому что два флага долговечности делают принципиально разные вещи. Главное правило защиты от краха — журнал упреждающей записи (write-ahead logging, WAL): прежде чем Postgres изменит страницу данных, он сначала дописывает компактную запись об изменении в WAL — последовательный, только-на-добавление лог. Только запись WAL должна быть сброшена на долговечное хранилище в момент коммита; сами страницы таблицы и индекса можно записать позже, лениво, фоновым писателем и checkpointer.

Почему это быстрее и безопаснее, чем запись самой страницы данных при коммите? Потому что записи WAL последовательны (дописывание в конец текущего файла лога), тогда как записи страниц данных случайны (разбросаны по heap). Форсировать один маленький последовательный fsync на коммит куда дешевле, чем форсировать много случайных записей страниц — и этого достаточно, потому что если машина падает до сброса грязных страниц, восстановление переигрывает WAL и реконструирует их. Страницы данных — оптимизация; WAL — источник истины.

-- Где WAL сейчас и как быстро он генерируется:
SELECT pg_current_wal_lsn();                       -- текущая позиция записи (LSN)
SHOW synchronous_commit;                            -- on | off | remote_apply ...
SHOW wal_level;                                     -- replica (по умолч.) | logical | minimal
SHOW max_wal_size;                                  -- мягкий потолок, запускающий checkpoint'ы

Рычаг долговечность/пропускная способность

synchronous_commit управляет, когда коммит подтверждается относительно сброса WAL:

• on (по умолчанию) — COMMIT ждёт, пока запись WAL не будет fsync-нута на долговечное хранилище. Закоммиченная транзакция переживёт крах. Полная долговечность, один fsync латентности на коммит.
• off — COMMIT возвращается немедленно после записи WAL в буфер ОС, до fsync. Сброс происходит асинхронно в пределах wal_writer_delay (≈200 мс). При крахе можно потерять последнюю долю секунды закоммиченных транзакций — но база остаётся консистентной (без повреждений, без рваного состояния), ты теряешь лишь хвост. В обмен пропускная способность на мелких транзакциях записи может подскочить в 2–3×, потому что коммиты больше не блокируются на диске.

Это самое значимое решение по тюнингу долговечности. Сеньорская формулировка: synchronous_commit = off — это не «небезопасно» так, как отключение fsync; он никогда не повреждает базу, он лишь расширяет окно потерянных-но-подтверждённых коммитов. Для платёжного реестра: никогда. Для аналитического конвейера загрузки, способного переиграть свой источник: часто это бесплатный 3× выигрыш.

Два связанных флага, которые путают: fsync = off — реально опасный; он позволяет самому WAL пропустить сброс на диск, так что крах может повредить кластер; никогда не используй вне одноразовой тестовой машины. А synchronous_commit = remote_apply расширяет долговечность до применения изменения репликой (см. репликацию ниже).

Checkpoint’ы ограничивают восстановление

Если бы WAL копился вечно, восстановление после краха переигрывало бы с начала времён. Checkpoint — периодический акт сброса всех грязных страниц данных в heap и записи: «всё до этой позиции WAL теперь безопасно на файлах данных». Восстановлению нужно переиграть WAL только после последнего checkpoint — поэтому частота checkpoint’ов ограничивает время восстановления.

Компромисс: частые checkpoint’ы — короткое восстановление, но больше постоянного I/O записи (частый сброс грязных страниц); редкие checkpoint’ы — меньше ровного I/O, но долгое, скачкообразное восстановление и большой WAL. Postgres запускает checkpoint, когда истекает checkpoint_timeout (по умолчанию 5 мин) или WAL достигает max_wal_size (по умолчанию 1 ГБ). Прод-тюнинг обычно повышает оба, чтобы checkpoint’ы были разреженнее, а пики записи сглажены, принимая более долгое восстановление — checkpoint_completion_target (по умолчанию 0.9) растягивает сброс по интервалу, избегая стены I/O.