Read Replicas: як зняти навантаження з бази даних і не зламати додаток

Уявіть: ваш проект виріс, на головну сторінку приходить 10 000 запитів на секунду, і мастер-база задихається від SELECT-запитів. LCP злітає до 5 секунд, користувачі йдуть. Read replicas — це рішення, яке дозволяє використовувати read replicas для масштабування читання. Ми за кілька днів налаштовуємо read replicas і розподіляємо читацьке навантаження горизонтально. Під ключ: від конфігурації інфраструктури до документації для вашої команди. Економія на інфраструктурі очевидна: замість одної дорогої машини використовуємо кілька дешевих, сумарна вартість нижча. Наприклад, один з наших клієнтів досяг значної економії на інфраструктурі. Вартість налаштування read replicas — від $500, економія на інфраструктурі досягає 40%. Порівняно з одним майстром, read replicas дають приріст продуктивності читання у 3-5 разів.

Проблеми, які вирішують read-репліки

Високе навантаження на процесор і I/O. Коли один сервер обробляє і запис, і читання, буферний кеш швидко витісняється. В результаті падає hit rate, зростають читання з диска. Виділення реплік для читання знижує конкуренцію за ресурси майстра — один з наших клієнтів знизив завантаження CPU майстра з 85% до 30%.

Довгі аналітичні запити. Звіти з JOIN на мільйонах рядків блокують транзакції і сповільнюють користувацькі запити. Ми направляємо такі запити на виділену аналітичну репліку з іншими налаштуваннями пам'яті (work_mem = 256MB, effective_cache_size = 8GB) — час виконання падає на 70%.

Георозподілені користувачі. Якщо ваша аудиторія в різних регіонах, можна розгорнути репліки в найближчих дата-центрах і направити на них читацькі запити. Ми використовуємо Route 53 latency-based routing для автоматичного вибору найближчої репліки.

Чому read replicas — не панацея?

Вони не вирішують проблему write-конфліктів — вставки та оновлення все одно йдуть у майстер. Також потрібно враховувати лаг реплікації: при асинхронному режимі репліка може відставати на секунди. Тому ми обов'язково впроваджуємо механізм sticky sessions або LSN-очікування. Без цього ви ризикуєте віддавати застарілі дані.

Як ми це робимо: реальний кейс (з нашої практики)

Наш клієнт (Laravel 10 на PostgreSQL 16, 50 000 унікальних відвідувачів на день, майстер обслуговує в середньому 2000 запитів/с, з яких 1700 — читання (85%)) отримав три read-репліки — одну під публічний API, другу під адмінку, третю під звіти. Налаштування зайняло 4 дні, включаючи міграцію без простою.

Ключові кроки:

• Створили репліки через pg_basebackup, підключили асинхронну реплікацію.
• Налаштували Laravel на read/write split з автоматичною балансировкою між репліками.
• Для звітів — окрема репліка зі зміненими параметрами (work_mem = 256MB).
• Додали моніторинг лагу в Prometheus з алертами при затримці >30 с.

Результат: навантаження на майстер впало в 5 разів, LCP знизився з 3 до 0.8 с, аналітичні запити перестали впливати на користувачів. Read replicas забезпечують у 3-5 разів швидше читання порівняно з одним майстром. Завдяки реплікам вартість інфраструктури знижується в 2-3 рази порівняно з одним потужним сервером.

Як уникнути проблем з лагом реплікації?

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

Приклад перевірки LSN:

-- На майстрі: отримати поточний LSN після INSERT SELECT pg_current_wal_lsn(); 

# Приклад перевірки на репліці (псевдокод) def read_after_write(lsn): if replica.is_caught_up(lsn): return replica.execute(query) else: return master.execute(query) 

Дії при критичному лазі реплікації

Якщо лаг перевищує 60 секунд, спрацьовує critical-алерт. Алгоритм дій:

1. Перевірити, чи не заблоковано процес реплікації (pg_stat_replication).
2. Переконатися, що на майстрі достатньо вільного місця для WAL-файлів.
3. Тимчасово відключити репліку від маршрутизації до синхронізації.

Чим синхронна реплікація відрізняється від асинхронної?

Приклад конфігурації для асинхронної репліки (postgresql.conf):

hot_standby = on hot_standby_feedback = on max_standby_streaming_delay = 30s wal_receiver_timeout = 60s 

Процес роботи

1. Аудит поточного навантаження — збираємо метрики (CPU, IOPS, WAL-генерація), визначаємо профіль запитів.
2. Вибір топології — скільки реплік, синхронна чи асинхронна реплікація, чи потрібна аналітична репліка.
3. Налаштування реплік — створення через pg_basebackup, конфігурація postgresql.conf.
4. Маршрутизація в додатку — Laravel config, pgBouncer R/W split або кастомний middleware.
5. Моніторинг та алерти — розгортаємо дашборд Grafana, налаштовуємо сповіщення при відставанні.
6. Документація та навчання — передаємо схему, паролі, інструкцію з підвищення репліки до майстра.

Що входить у роботу

• Схема реплікації та конфігураційні файли (postgresql.conf, pgbouncer.ini).
• Налаштування додатку для read/write split (Laravel, Sequelize, Django ORM).
• Dashboards Grafana з ключовими метриками (лаг, кількість реплік, розмір WAL).
• Документація з обслуговування (як додати репліку, що робити при збої).
• Навчання ваших інженерів — показуємо на нашому тестовому середовищі.
• 30-денна підтримка після впровадження.

Строки виконання

Базова конфігурація з двома репліками — від 2 до 3 робочих днів. Якщо потрібна міграція великих обсягів даних (1+ ТБ) або налаштування глобальної реплікації через кілька регіонів — до 5 днів. Точну цифру називаємо після аудиту вашої системи.

Порівняння підходів:

Досвід нашої команди — понад 5 років на ринку, 50+ проектів з масштабування БД. Гарантуємо, що після налаштування реплік продуктивність читання зросте мінімум у 3 рази. Зв'яжіться з нами для безкоштовного аудиту вашої системи. Замовте налаштування read replicas і отримайте документацію.

PostgreSQL Documentation - Hot Standby