Все заметки
Это главное что нужно знать. PostgreSQL записывает каждое изменение в специальный лог перед тем как применить его к реальным файлам данных. Если база крашится - она воспроизводит этот лог начиная с последней контрольной точки и восстанавливает все подтверждённые транзакции.
Это называется WAL - Write-Ahead Log. Буквально «лог опережающей записи».
Каждое изменение в PostgreSQL записывается дважды. Сначала в WAL. Потом уже в реальную таблицу.
WAL - это как чёрный ящик самолёта. Когда самолёт разбивается, следователи используют чёрный ящик чтобы восстановить что произошло. WAL - это эквивалент для базы данных. Он фиксирует каждое запланированное изменение в последовательном формате только для добавления. Даже если страницы данных повреждены при краше, WAL даёт системе источник правды для восстановления.
Представь сценарий: пользователь делает банковский перевод. Приложение подтвердило успех - но сервер упал миллисекундой позже.
Если бы не WAL - та транзакция могла бы никогда не попасть в базу: баланс отправителя был уменьшен в памяти но не записан на диск. Это катастрофический сбой надёжности.
С WAL всё иначе. Перевод уже зафиксирован в логе до того как сервер упал. При восстановлении PostgreSQL его найдёт и применит.
Когда PostgreSQL стартует после краша он находит последнюю валидную контрольную точку. Файлы данных восстанавливаются до состояния на момент этой точки. Затем записи WAL после контрольной точки воспроизводятся последовательно. Применяются только подтверждённые транзакции.
Весь этот процесс происходит автоматически - тебе ничего не нужно делать. PostgreSQL сам понимает что был краш, сам находит где остановился и сам восстанавливается.
Периодически PostgreSQL делает checkpoint - сбрасывает все «грязные» страницы из памяти на диск. Это сокращает время восстановления: не нужно воспроизводить весь WAL с самого начала, только с последнего checkpoint.
Чем чаще checkpoint - тем быстрее восстановление после краша, но больше нагрузка на диск в обычной работе. Золотая середина настраивается через
Никогда не удаляй файлы WAL вручную. PostgreSQL управляет жизненным циклом WAL самостоятельно. Ручное удаление может сломать
PostgreSQL надёжный не потому что не падает - падает всё. Он надёжный потому что знает как подняться. WAL это фундамент на котором держится вся эта надёжность. Именно поэтому я выбрал Postgres и использую его везде - это база которой можно доверять. 🐘
Что происходит когда PostgreSQL крашится
Я использую PostgreSQL практически во всех рабочих проектах. И всегда было интересно: что реально происходит под капотом когда база падает? Давайте разберём.
Коротко: данные не теряются
Это главное что нужно знать. PostgreSQL записывает каждое изменение в специальный лог перед тем как применить его к реальным файлам данных. Если база крашится - она воспроизводит этот лог начиная с последней контрольной точки и восстанавливает все подтверждённые транзакции.
Это называется WAL - Write-Ahead Log. Буквально «лог опережающей записи».
Что такое WAL
Каждое изменение в PostgreSQL записывается дважды. Сначала в WAL. Потом уже в реальную таблицу.
WAL - это как чёрный ящик самолёта. Когда самолёт разбивается, следователи используют чёрный ящик чтобы восстановить что произошло. WAL - это эквивалент для базы данных. Он фиксирует каждое запланированное изменение в последовательном формате только для добавления. Даже если страницы данных повреждены при краше, WAL даёт системе источник правды для восстановления.
Что происходит в момент краша
Представь сценарий: пользователь делает банковский перевод. Приложение подтвердило успех - но сервер упал миллисекундой позже.
Если бы не WAL - та транзакция могла бы никогда не попасть в базу: баланс отправителя был уменьшен в памяти но не записан на диск. Это катастрофический сбой надёжности.
С WAL всё иначе. Перевод уже зафиксирован в логе до того как сервер упал. При восстановлении PostgreSQL его найдёт и применит.
Процесс восстановления шаг за шагом
Когда PostgreSQL стартует после краша он находит последнюю валидную контрольную точку. Файлы данных восстанавливаются до состояния на момент этой точки. Затем записи WAL после контрольной точки воспроизводятся последовательно. Применяются только подтверждённые транзакции.
Весь этот процесс происходит автоматически - тебе ничего не нужно делать. PostgreSQL сам понимает что был краш, сам находит где остановился и сам восстанавливается.
Контрольные точки (Checkpoints)
Периодически PostgreSQL делает checkpoint - сбрасывает все «грязные» страницы из памяти на диск. Это сокращает время восстановления: не нужно воспроизводить весь WAL с самого начала, только с последнего checkpoint.
Чем чаще checkpoint - тем быстрее восстановление после краша, но больше нагрузка на диск в обычной работе. Золотая середина настраивается через
max_wal_size и checkpoint_completion_target в postgresql.conf.
Важное правило
Никогда не удаляй файлы WAL вручную. PostgreSQL управляет жизненным циклом WAL самостоятельно. Ручное удаление может сломать
crash recovery, бэкапы и репликацию. Если заканчивается место на диске - решение в конфигурации и мониторинге, не в ручной чистке.
Итог
PostgreSQL надёжный не потому что не падает - падает всё. Он надёжный потому что знает как подняться. WAL это фундамент на котором держится вся эта надёжность. Именно поэтому я выбрал Postgres и использую его везде - это база которой можно доверять. 🐘
Комментарии