Журнал попереднього запису WAL

Пізніше фонова підсистема записує змінену сторінку даних у файли таблиць.

Якщо сервер аварійно зупинився між кроками 4 і 5, сторінка даних може ще не містити зміни. Під час наступного запуску PostgreSQL прочитає WAL і повторить потрібну операцію над сторінкою.

Цей процес називається crash recovery, або аварійне відновлення.

Чому не записувати сторінки одразу

Запис змінених сторінок на диск для кожної операції був би повільним і складним. Одна транзакція може змінити багато сторінок, а різні сторінки можуть розташовуватися далеко одна від одної на диску.

WAL дає змогу:

• послідовно записувати журнал;

• групувати записи кількох транзакцій;

• відкладати запис сторінок даних;

• відновлювати зміни після збою.

Послідовний запис журналу зазвичай ефективніший за випадковий запис багатьох сторінок даних.

LSN — позиція в журналі

Кожен WAL-запис має позицію в журналі, яка називається LSN — Log Sequence Number.

LSN записується у вигляді на кшталт:

Це не номер рядка і не час. LSN позначає позицію у потоці WAL та дає змогу порівнювати порядок записів:

• більший LSN означає пізніший запис;

• за LSN можна оцінити обсяг згенерованого WAL;

• LSN використовують під час реплікації, резервного копіювання та відновлення.

Подивитися поточні позиції можна SQL-запитами:

pg_current_wal_insert_lsn() показує позицію, до якої WAL було вставлено записи.

pg_current_wal_flush_lsn() показує позицію, до якої WAL було скинуто на диск поточним сервером.

Різниця між цими значеннями може свідчити про WAL, який ще перебуває в буферах і не був скинутий на диск.

WAL-сегменти

WAL зберігається не в одному нескінченному файлі, а в окремих файлах — сегментах WAL.

У стандартній конфігурації розмір сегмента становить 16 МБ. Розмір визначається під час створення кластера бази даних і не змінюється звичайною зміною параметра конфігурації.

Файли WAL зберігаються в каталозі:

У старіших версіях PostgreSQL цей каталог називався pg_xlog.

Назва WAL-файлу має шістнадцятковий формат, наприклад:

Назва містить інформацію про:

• timeline;

• старшу частину логічної позиції;

• номер сегмента.

Точну назву сегмента для поточного LSN можна отримати так:

Оцінити відстань між двома позиціями можна за допомогою pg_wal_lsn_diff:

У реальному кластері позицію '0/0' зазвичай замінюють на LSN, отриманий раніше, наприклад на початку вимірювання.

Життєвий цикл сегмента

Коли поточний сегмент заповнюється, PostgreSQL переходить до наступного. Старі сегменти можуть:

• бути повторно використані;

• бути видалені;

• залишатися в pg_wal, якщо вони ще потрібні для реплікації або архівації.

Кількість файлів у pg_wal не дорівнює кількості всього WAL, який коли-небудь створювався. PostgreSQL зазвичай повторно використовує старі сегменти.

Не можна вручну видаляти файли з pg_wal. Це може зробити кластер непридатним для запуску або зруйнувати можливість відновлення.

Checkpoint і WAL

Checkpoint — це момент, коли PostgreSQL записує на диск достатню кількість змінених сторінок даних і створює в WAL контрольну точку.

Під час запуску після збою PostgreSQL не обов’язково читає весь WAL від початку історії. Він знаходить останній відповідний checkpoint і продовжує відновлення з нього.

Основні параметри checkpoint:

• checkpoint_timeout задає максимальний інтервал між автоматичними checkpoint;

• max_wal_size визначає приблизний обсяг WAL, після якого checkpoint може бути запущений;

• min_wal_size впливає на мінімальну кількість WAL, яку PostgreSQL намагається зберігати для повторного використання.

Checkpoint не означає, що WAL більше не потрібен у будь-якому сценарії. Для архівації, відновлення до моменту в часі та реплікації можуть бути потрібні значно старші WAL-сегменти.

Відновлення після збою

Після аварійного завершення PostgreSQL під час запуску перевіряє стан контрольних файлів і знаходить незавершене коректне завершення роботи.

Далі сервер:

1. знаходить останню контрольну точку;

2. читає WAL після неї;

3. повторює необхідні зміни сторінок;

4. відновлює узгоджений стан;

5. робить базу доступною для підключень.

WAL-запис описує операцію на сторінці, а не обов’язково повний новий стан рядка. Тому для коректного відновлення PostgreSQL використовує внутрішню структуру сторінок, ідентифікатори блоків та інші службові дані.

Параметр full_page_writes захищає від проблеми часткового запису сторінки. Якщо збій станеться під час запису сторінки, на диску можуть опинитися частини старого та нового вмісту. Після checkpoint PostgreSQL може записати повну копію зміненої сторінки у WAL, щоб відновлення могло замінити пошкоджений варіант.

Перевірити параметри можна так:

Для звичайного надійного режиму зазвичай очікують:

• fsync = on;

• full_page_writes = on;

• wal_level не нижче replica.

Не слід вимикати fsync або full_page_writes у робочій базі без чіткого розуміння наслідків.

WAL і підтвердження транзакції

Під час виконання COMMIT клієнт отримує підтвердження не просто після зміни сторінки в пам’яті. PostgreSQL також враховує, коли WAL було скинуто на диск.

Поведінка залежить від synchronous_commit.

За значенням:

можна побачити поточний режим.

У звичайному режимі on транзакція вважається підтвердженою після того, як її WAL надійно скинуто на локальний диск. Це зменшує ризик втрати вже підтверджених транзакцій після аварії.

Якщо застосунок використовує менш строгий режим, сервер може повернути успішний результат раніше, ніж WAL буде скинуто на диск. У такому разі після збою невелика кількість уже підтверджених транзакцій може бути втрачена.

Це компроміс між продуктивністю та довговічністю підтверджених змін.

Архівація WAL

Самих WAL-файлів у pg_wal недостатньо для довготривалого відновлення. PostgreSQL може повторно використати або видалити старий сегмент, коли він більше не потрібен локальному серверу.

Щоб зберігати WAL поза основним кластером, використовують WAL-архівацію.

Архівація потрібна для:

• відновлення бази після втрати основного диска;

• point-in-time recovery;

• зберігання безперервного ланцюжка змін між базовими резервними копіями;

• перенесення WAL на інший сервер.

Для ввімкнення архівації потрібно налаштувати щонайменше:

archive_mode вмикають на рівні кластера, і для його зміни потрібен перезапуск сервера.

archive_command — це команда операційної системи. PostgreSQL виконує її для кожного завершеного WAL-сегмента.

У команді доступні спеціальні підстановки:

• %p — повний шлях до локального WAL-файлу;

• %f — ім’я WAL-файлу без шляху.

Наприклад, для локального тестового архіву:

Перед цим каталог архіву має існувати, а користувач PostgreSQL — мати до нього доступ.

Команда повинна завершуватися кодом 0 лише після успішного збереження WAL-файлу. Якщо команда завершується ненульовим кодом, PostgreSQL вважає архівацію невдалою і спробує виконати її знову.

Вимоги до надійної archive_command

Команда архівації повинна бути:

• ідемпотентною;

• безпечною при повторному запуску;

• здатною повідомити про помилку;

• достатньо швидкою, щоб архіватор не відставав від генерації WAL;

• спрямованою на окреме сховище, бажано не на той самий диск.

Поширена помилка — використовувати команду, яка завжди повертає успішний код, навіть якщо копіювання не відбулося. У такому випадку PostgreSQL може вважати сегмент заархівованим, хоча файл фактично втрачено.

Ще одна помилка — зберігати архів на тому самому диску, що й PGDATA. Це не захищає від відмови диска.

Перевірка стану архівації

Стан архіватора можна перевірити так:

Особливо важливі поля:

• archived_count — кількість успішно заархівованих сегментів;

• failed_count — кількість невдалих спроб;

• last_archived_wal — останній заархівований файл;

• last_failed_wal — останній файл, архівація якого завершилася помилкою.

Зростання failed_count потребує перевірки дискового простору, дозволів, доступності архівного сховища та самої команди.

Коли PostgreSQL створює новий сегмент

За нормального навантаження новий WAL-сегмент створюється після заповнення поточного. Для тестування або керування моментом перемикання можна використати:

Функція завершує поточний WAL-сегмент і переходить до нового. Це не означає, що новий сегмент одразу буде заархівований: архіватор ще має отримати його та успішно виконати archive_command.

Параметр archive_timeout дає змогу примусово перемикати сегмент, якщо протягом заданого часу не набралося достатньо WAL:

Це може бути корисно для систем із низькою активністю, де потрібно регулярно доставляти WAL до архіву. Водночас занадто мале значення створює багато частково заповнених сегментів і збільшує накладні витрати.

Базова резервна копія та WAL

Для повного відновлення до певного моменту потрібні дві складові:

1. базова резервна копія кластера;

2. безперервний ланцюжок WAL, створений після цієї копії.

WAL сам по собі не замінює базову резервну копію. Він описує зміни, але не містить повної початкової копії всіх файлів даних.

Типовий процес виглядає так:

1. створити базову резервну копію;

2. зберігати всі WAL-сегменти, створені після її початку;

3. під час відновлення розгорнути базову копію;

4. передати PostgreSQL архівовані WAL;

5. відтворити зміни до потрібного моменту.

Якщо хоча б один необхідний WAL-сегмент втрачений, безперервність ланцюжка порушується, і відновлення до пізнішого моменту може стати неможливим.

Відновлення до моменту часу

Point-in-time recovery, або PITR, дає змогу відновити базу не лише до стану останньої резервної копії, а до певного моменту в часі.

Наприклад, якщо помилкова команда DELETE була виконана о 14:30, можна відновити копію до 14:29:59 — за умови, що є базова копія та всі необхідні WAL.

Під час налаштування відновлення PostgreSQL використовує параметри на кшталт:

Тут:

• %f — ім’я WAL-файлу, який потрібно отримати;

• %p — шлях, куди його потрібно скопіювати.

Для сучасних версій PostgreSQL сценарій відновлення також визначається параметрами цілі відновлення та спеціальним файлом сигналу, наприклад recovery.signal.

Важливо, що restore_command має повертати ненульовий код, якщо потрібного WAL-файлу ще немає або його неможливо отримати. Це дає серверу змогу коректно керувати пошуком наступних файлів.

Моніторинг використання WAL

Корисно регулярно перевіряти:

• розмір каталогу pg_wal;

• стан WAL-архіватора;

• кількість невдалих архівацій;

• затримку архівування;

• генерацію WAL під навантаженням;

• наявність вільного місця.

Поточний розмір WAL можна оцінити в операційній системі:

Поточну позицію та назву WAL-файлу — у PostgreSQL:

Для вимірювання генерації WAL можна зняти дві позиції з інтервалом:

Різницю можна обчислити так:

У практичному сценарії замість наведених позицій використовують значення з попередніх вимірювань.

Типові помилки

Видалення файлів із pg_wal

Видаляти WAL-файли вручну небезпечно. PostgreSQL сам визначає, які сегменти ще потрібні.

Якщо pg_wal переповнюється, потрібно шукати причину:

• архівація не працює;

• реплікація відстає;

• активна транзакція утримує старі дані;

• неправильно працює слот реплікації;

• недостатньо місця в архівному сховищі.

Перевірка лише наявності файлу

Файл може існувати в архіві, але бути пошкодженим або неповністю скопійованим. Команда архівації повинна вважати операцію успішною лише після завершення повного копіювання.

Архівація на той самий диск

Копія WAL у сусідній каталог не захистить від відмови диска або втрати сервера. Архів потрібно зберігати окремо та регулярно перевіряти можливість його читання.

Вимкнення fsync

fsync = off може прискорити тимчасові тести, але створює ризик пошкодження даних після збою. Для робочого кластера це зазвичай неприйнятний режим.

Надто малий archive_timeout

Надто часте перемикання сегментів може створювати багато частково заповнених WAL-файлів. Значення потрібно вибирати з урахуванням вимог до відновлення та обсягу навантаження.

Припущення, що WAL — це аудит

WAL не призначений для перегляду історії дій користувачів або відновлення попередніх значень рядків у зручному для людини форматі. Для аудиту потрібні інші механізми.

Підсумок

• WAL — це журнал попереднього запису, який PostgreSQL використовує для надійності та відновлення.

• Запис у WAL має бути збережений до запису відповідної сторінки даних.

• WAL зберігається у послідовності сегментів, зазвичай розміром 16 МБ.

• LSN визначає позицію запису в WAL і використовується для контролю прогресу.

• Після аварії PostgreSQL читає WAL після checkpoint і відновлює узгоджений стан.

• Архівація WAL потрібна для захисту від втрати основного кластера та point-in-time recovery.

• Для PITR потрібні базова резервна копія та безперервний набір WAL після неї.

• archive_command має бути надійною, ідемпотентною та правильно повідомляти про помилки.

• Файли з pg_wal не можна видаляти вручну.

• Стан архівації потрібно контролювати через pg_stat_archiver і системний моніторинг.