RDB: снапшоты

RDB — это бинарный снимок всего датасета на момент времени: один компактный файл, идеально подходящий для бэкапов. Плата за это — окно потери данных между снимками.

Настройка

# redis.conf: правило "N изменений за M секунд → снимок"
save 900 1        # ≥1 изменения за 15 минут
save 300 10       # ≥10 за 5 минут
save 60 10000     # ≥10000 за минуту
dbfilename dump.rdb
dir /var/lib/redis   # куда писать

# Ручной снимок (не блокирует клиентов)
BGSAVE
# Синхронный SAVE — только для отладки: блокирует сервер!

Изменённые команды срабатываний: INFO persistence показывает rdb_last_save_time, rdb_changes_since_last_save, rdb_last_bgsave_status (должен быть ok) и rdb_last_bgsave_time_sec.

Как снимок делается: fork + copy-on-write

1. Redis делает fork(): появляется дочерний процесс с копией адресного пространства — но страницы памяти общие, копирования ещё не было;
2. ребёнок сериализует датасет во временный файл и атомарно переименовывает его в dump.rdb;
3. родитель тем временем продолжает обслуживать команды; при записи в страницу ОС создаёт её копию (copy-on-write) — родитель живёт дальше, ребёнок видит снимок «как был».

⚠️ Два следствия fork: (1) пауза на fork — копирование таблиц страниц памяти; на 10+ ГБ датасете это десятки–сотни мс (latest_fork_usec); (2) COW-память — при активной записи во время снимка изменённые страницы дублируются: потребление может вырасти до +100% от датасета. Планируйте RAM: used_memory ≤ 50–60% хоста, если BGSAVE частый.

Дисковая hygiene

• Следите за свободным местом: если диск полон, BGSAVE падает, и снапшоты перестают обновляться молча (алерт на rdb_last_bgsave_status обязателен);
• в контейнерах монтируйте dir на volume — иначе дамп умирает с контейнером;
• RDB — точка во времени: бэкап файла сам по себе бессмыслен без регулярности.

Плюсы и минусы

Когда RDB достаточно

• Чистый кеш: потеря = прогрев, не инцидент. Можно даже без персистентности вовсе (save "");
• Вторичные данные: рейтинги, счётчики, сессии с повторным логином;
• Как «точка восстановления» в дополнение к AOF (стандартная связка — оба механизма).

Практика

1. Включите RDB, залейте данные, BGSAVE; посмотрите INFO persistence и найдите dump.rdb в volume.
2. Убейте контейнер (docker kill), поднимите с тем же volume — проверьте DUMP-выборку и DBSIZE: что вернулось, что потерялось?
3. Замерьте latest_fork_usec на датасете 100 МБ, 500 МБ, 1 ГБ — постройте зависимость паузы от размера.
4. Включите stop-writes-on-bgsave-error yes (дефолт) и заполните диск — убедитесь, что записи блокируются, а не теряются молча.