За замовчуванням Redis — in-memory база даних. При рестарті всі дані втрачаються. Для більшості сценаріїв це нормально, якщо Redis використовується лише як кеш. Але якщо в Redis зберігаються черги завдань, сесії, лічильники або інші дані, які не можна втратити — потрібна персистентність. Ми стикалися з цим на кожному другому проєкті: без RDB або AOF клієнти втрачали операційні дані, і доводилося відновлювати їх із резервних копій вручну. Наприклад, на проєкті з чергами завдань ми втрачали до 5 хвилин даних між знімками RDB, що призводило до задвоєння замовлень. Після впровадження AOF з everysec втрати скоротилися до 1 секунди. Налаштування Redis Persistence — базова задача для будь-якого продакшн-сервісу з вимогами до збереження даних. Розглянемо обидва механізми та їх спільне використання.
Є два механізми: RDB (знімки) та AOF (append-only file). Їх можна використовувати окремо або разом. Правильна конфігурація — фундамент надійного відновлення з втратою не більше секунди.
Як працює RDB?
RDB зберігає повний знімок даних у бінарний файл dump.rdb. Налаштування через директиву save:
save 900 1 save 300 10 save 60 10000 Це означає: зберігати, якщо за 900 секунд змінився хоча б 1 ключ, або за 300 секунд — 10 ключів, або за 60 секунд — 10000 ключів. При рестарті Redis завантажує останній dump.rdb.
Головний мінус RDB — втрата даних між знімками. Якщо Redis впав за 5 хвилин до наступного знімка — втратили 5 хвилин змін. На high-load проєктах це критично.
Згідно з офіційною документацією Redis, знімок виконується через fork() — створюється дочірній процес, який пише дані на диск, поки батьківський продовжує обслужити запити. На час fork() Redis може трохи зависнути (latency spikes) — на великій базі (10+ GB) це може бути кілька секунд. Критично для low-latency застосунків.
Ручний знімок без блокування: BGSAVE. З блокуванням (для backup): SAVE.
Що таке AOF?
AOF пише кожну команду запису в лог-файл. При рестарті Redis відтворює весь AOF для відновлення даних.
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mbappendfsync — ключовий параметр:
- always — fsync після кожної команди. Максимальна надійність, мінімальна швидкість.
- everysec — fsync кожну секунду. Втрата максимум 1 секунди даних при збої. Баланс надійності та продуктивності.
- no — fsync за рішенням ОС. Швидко, але втрата даних непередбачувана.
everysec — правильний вибір для більшості випадків.
AOF з часом зростає. auto-aof-rewrite-percentage 100 означає: коли файл подвоїться відносно свого розміру після останнього перезапису — запустити BGREWRITEAOF, який створює компактний AOF лише з актуальними командами (без проміжних SET/DEL одного ключа).
Детальніше про AOF rewrite
AOF rewrite використовує дочірній процес, аналогічно BGSAVE, але замість знімка створює новий компактний журнал. Під час rewrite Redis продовжує приймати запис у старий AOF. Після завершення новий файл атомарно замінює старий. Процес керується директивами auto-aof-rewrite-percentage та auto-aof-rewrite-min-size. Для великих файлів (>10 GB) може знадобитися ручний запуск BGREWRITEAOF у години низького навантаження.Чому варто використовувати обидва механізми разом?
При включенні обох механізмів при рестарті Redis використовує AOF (він точніше). RDB залишається як швидкий знімок для бекапів.
save 900 1 appendonly yes appendfsync everysec Це рекомендована конфігурація для продакшну, де важлива збереженість даних. Ми використовуємо її на 80% проєктів, включаючи high-load сервіси.
Як вибрати між RDB і AOF?
Порівняємо ключові параметри:
| Параметр | RDB | AOF |
|---|---|---|
| Формат | Бінарний знімок | Журнал команд |
| Розмір файлу | Компактний | Більше (але rewrite допомагає) |
| Втрата даних | Між знімками (хвилини) | До 1 сек (everysec) |
| Швидкість відновлення | Швидка (один файл) | Повільніше (відтворення команд) |
| Вплив на продуктивність | Fork + I/O at snapshot | I/O на кожен запис (fsync) |
| Ручне керування | BGSAVE / SAVE | BGREWRITEAOF |
Адаптація під конкретні сценарії:
| Сценарій | Рекомендований підхід | Обґрунтування |
|---|---|---|
| Кеш (дані відновлюються) | Без персистентності | Максимальна продуктивність, немає fork |
| Черги, сесії | RDB + AOF everysec | Гарантія відновлення з втратою не більше 1 секунди |
| Лічильники, аналітика | Тільки AOF everysec | Компактніше, ніж RDB, при частих записах |
| Мікросервіси з low-latency | AOF everysec + disable fork | Уникаємо latency spikes від fork |
Для сценарію «тільки кеш»
Якщо Redis — чистий кеш, і при рестарті дані можна прогріти заново:
save "" appendonly no Вимкнути всі механізми персистентності. Redis буде швидше (немає I/O на disk), і fork() для знімків не викликатиме latency spikes. Економія ресурсів CPU та RAM — до 30% залежно від навантаження.
Як ми налаштовуємо Redis Persistence під ключ
Процес займає від 2 до 3 днів залежно від обсягу даних та вимог до відмовостійкості:
- Аналіз навантаження та сценаріїв — визначаємо, чи потрібна персистентність, обираємо механізми.
- Конфігурація — налаштування save-інтервалів, параметрів AOF, rewrite, fsync.
- Тестування відновлення — симулюємо збій, перевіряємо, що дані відновлюються за очікуваний час.
- Моніторинг — додаємо метрики (RDB duration, AOF rewrite, fork latency) у Prometheus/Grafana.
- Документація та навчання — фіксуємо runbook для чергової зміни.
Що входить у роботу
- Конфігурація RDB та AOF через Ansible (Terraform).
- Тести продуктивності та відновлення (результати у звіті).
- Моніторинг: дашборди Grafana, алерти по fork latency.
- Документування runbook: як перевірити, перезапустити, вирішити проблему.
- Навчання команди: 1 година онлайн з демонстрацією.
Часті помилки при налаштуванні
- Використання appendfsync always без необхідності — викликає 10-кратне падіння IOPS.
- Занадто часті save (кожні 60 секунд при 10k змін) — перевантаження диска.
- Забувають про AOF rewrite — файл розростається до десятків гігабайт.
- Налаштування stop-writes-on-bgsave-error no — ризикуєте втратити дані при збої знімка.
Гарантії та досвід
Вартість налаштування розраховується індивідуально залежно від складності архітектури. Гарантуємо відновлення даних у задані RTO/RPO за умови збереження логів. Досвід роботи з Redis — понад 5 років, 50+ успішних проєктів у продакшні. Для оцінки вашого проєкту зв'яжіться з нами — ми підберемо оптимальну конфігурацію та перевіримо її на вашому стенді. Отримайте консультацію вже сьогодні.
Замовте налаштування Redis Persistence у досвідчених інженерів — забезпечимо відмовостійкість вашого сервісу.
