Реплікація і відмовостійкість у PostgreSQL

Як репліка дізнається про зміни

Потокова реплікація в PostgreSQL будується навколо Write-Ahead Log (WAL) — журналу, в який сервер записує кожну зміну до того, як застосувати її до даних. Репліка підключається до primary-сервера і безперервно отримує потік записів WAL, застосовуючи їх у себе, щоб залишатися синхронізованою копією. Детальніше про суміжний підхід можна прочитати в матеріалі «Оптимізація N+1 запитів в ORM».

Синхронна і асинхронна реплікація

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

Синхронна реплікація вирішує цю проблему, вимагаючи підтвердження від щонайменше однієї репліки перед підтвердженням транзакції клієнту — ціною додаткової затримки на кожен запис. Для продакшен-систем часто обирають компроміс: одна синхронна репліка для критичних даних і кілька асинхронних для розподілу навантаження на читання та географічної відмовостійкості. Ці ідеї перегукуються з темами «Транзакції та рівні ізоляції в SQL» та «Contract-тестування мікросервісів».