Лучшие практики предотвращения потери данных: настройка RDB и AOF

Персистентность Redis легко неправильно понять, потому что Redis ощущается как база данных, но ведет себя в первую очередь как память. Если перезапустить его без персистентности, данные исчезнут. Если персистентность включена, но настроена небрежно, вы все равно можете потерять недавние записи, заблокировать клиентов при нагрузке на диск или обнаружить во время сбоя, что единственная копия ваших данных находится на том же отказавшем томе, что и процесс Redis.

Правильная стратегия предотвращения потери данных в Redis начинается с одного честного вопроса: что произойдет, если исчезнут последние несколько секунд, минут или часов записей? Кэш страниц продуктов обычно можно восстановить. Хранилище сессий может раздражать пользователей, но не разрушить бизнес. Очередь, журнал ограничения скорости, хранилище корзины покупок или хранилище функциональных флагов могут требовать гораздо более строгой долговечности. RDB и AOF — это два инструмента, которые дает Redis, и они решают разные части этой проблемы.

Понимание механизмов персистентности Redis

У Redis есть два основных режима персистентности:

RDB-снимки

RDB записывает моментальный снимок набора данных на диск, обычно как dump.rdb. Redis создает дочерний процесс, дочерний процесс сериализует набор данных, а родительский продолжает обслуживать клиентов. Это делает RDB полезным для резервного копирования, реплик и быстрых перезапусков, но у него есть явный компромисс: все, что записано после последнего успешного снимка, может быть потеряно при сбое процесса или хоста.

Типичные настройки RDB выглядят так:

save 900 1       # Сохранять через 15 минут, если изменился хотя бы 1 ключ
save 300 10      # Сохранять через 5 минут, если изменилось хотя бы 10 ключей
save 60 10000    # Сохранять через 1 минуту, если изменилось хотя бы 10000 ключей
dbfilename dump.rdb
dir /var/lib/redis

Эти строки save не являются обещанием, что Redis сохранит точно по этому расписанию. Это правила-триггеры: если за интервал изменилось достаточно ключей, Redis запускает фоновое сохранение. Если диск медленный, набор данных огромен или на хосте мало памяти, фоновое сохранение может завершиться ошибкой или создать задержки из-за fork и copy-on-write.

RDB наиболее силен, когда вам нужны компактные снимки и быстрое восстановление. Он наиболее слаб, когда ваша терпимость к недавней потере данных низка.

AOF-логирование

AOF (append-only file) записывает команды записи, чтобы Redis мог воспроизвести их при перезапуске. Обычно он обеспечивает лучшую долговечность, чем RDB, потому что может сбрасывать записи чаще, чем по расписанию снимков. Компромисс — больше операций ввода-вывода на диск, большие файлы до перезаписи и иногда более медленный запуск, если Redis приходится воспроизводить большой журнал.

Основные настройки:

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

Важная строка — appendfsync. С everysec Redis просит операционную систему сбрасывать AOF примерно раз в секунду. При обычном сбое процесса Redis это обычно ограничивает потерю примерно последней секундой записей. При полном сбое хоста или хранилища точная потеря зависит от ОС, файловой системы, дискового кэша и поведения хранилища, поэтому не описывайте это как математическую гарантию.

appendfsync always сбрасывает после каждой записи и намного дороже. Это может быть уместно для небольшого критически важного развертывания Redis со скромным объемом записи, но может сильно ухудшить задержку при реальном трафике. appendfsync no позволяет ОС решать, когда сбрасывать; это быстро, но дает гораздо более широкое и менее предсказуемое окно потери.

Лучшие практики предотвращения потери данных

Используйте оба только когда понимаете, какой файл загрузит Redis

Многие производственные развертывания Redis включают и RDB, и AOF. Это разумное значение по умолчанию, когда Redis хранит данные, которые было бы болезненно восстанавливать. RDB дает компактные артефакты резервного копирования. AOF дает меньшее окно недавних потерь.

Используйте такую конфигурацию:

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Одна деталь важна при восстановлении: когда AOF включен, Redis обычно загружает данные AOF при запуске, так как ожидается, что они более полны, чем RDB-снимок. Не предполагайте, что Redis загрузит RDB первым и переключится на AOF. Протестируйте путь восстановления для вашей версии Redis и схемы развертывания, особенно на версиях Redis, использующих новый многокомпонентный формат AOF.

Выбирайте appendfsync исходя из окна потери

Начните с бизнес-влияния, а не с настройки Redis.

Если Redis — это одноразовый кэш, может быть достаточно только RDB или даже отсутствия персистентности, если ваше приложение безопасно восстанавливает данные. Если Redis содержит сессии, appendfsync everysec часто является практичным балансом. Если Redis является частью рабочего процесса, где потеря подтвержденных записей наносит реальный бизнес-ущерб, одной персистентности Redis может быть недостаточно. Вам может понадобиться основная база данных, долговечная очередь или упреждающее журналирование на уровне приложения вне Redis.

Для большинства операционных случаев использования Redis начните с:

appendonly yes
appendfsync everysec

Затем следите за задержкой, временем записи на диск, поведением перезаписи AOF и временем перезапуска, прежде чем решать, двигаться ли к always или отказываться от AOF.

Сохраняйте RDB-снимки, но не делайте их слишком частыми

Частые сохранения RDB уменьшают объем данных, теряемых между снимками, но также увеличивают частоту fork. Форкинг большого процесса Redis может быть дорогим, а записи во время сохранения дочерним процессом создают давление на память из-за copy-on-write. Если ваш экземпляр Redis имеет набор данных 40 ГБ и высокая скорость записи, сохранение каждую минуту может ухудшить надежность, потому что хост проводит слишком много времени под давлением памяти и диска.

Разумные правила сохранения RDB зависят от скорости записи и ожиданий по восстановлению. Небольшой кэш может делать снимки часто без проблем. Большое хранилище сессий может нуждаться в меньшем количестве RDB-снимков плюс AOF для недавней долговечности. Следите за INFO persistence, журналами Redis и памятью хоста во время BGSAVE, а не только за файлом конфигурации Redis.

Относитесь к перезаписи AOF как к обычному обслуживанию, а не к аварийной ситуации

Файлы AOF растут, потому что они записывают команды. Redis перезаписывает их в компактное представление в фоновом режиме. Значения по умолчанию часто являются хорошей отправной точкой:

aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

Это означает, что Redis рассматривает перезапись, когда AOF значительно вырос по сравнению с размером после предыдущей перезаписи, при условии, что он достиг минимального размера. Если перезаписи происходят постоянно, увеличьте минимальный размер или исследуйте шумный шаблон записи. Если AOF долго растет без перезаписи, проверьте журналы, дисковое пространство и INFO persistence.

Вы можете запустить перезапись вручную:

redis-cli BGREWRITEAOF

Делайте это в тихий период, если возможно. Перезапись безопаснее, чем позволять файлу расти бесконечно, но она все равно потребляет ЦП, пропускную способность диска и память copy-on-write.

Резервируйте файлы персистентности где-то еще

Персистентность — это не резервное копирование. Файлы персистентности на том же хосте защищают вас от перезапуска процесса Redis. Они не защищают вас от потери диска, случайного удаления, неудачного развертывания, перезаписывающего каталог данных, или ошибки оператора, запускающего FLUSHALL.

Копируйте файлы RDB и AOF в отдельное хранилище. Если вы используете снимки файловой системы или облачные снимки томов, протестируйте восстановление на отдельном экземпляре. Для копий RDB предпочтительнее копировать завершенный файл снимка, а не файл, который записывается. Для AOF изучите структуру файла для вашей версии Redis, прежде чем создавать скрипты резервного копирования на основе имен файлов.

Следите за сигналами, предсказывающими потерю данных

Полезная команда во время инцидента:

redis-cli INFO persistence

Ищите неудачные фоновые сохранения, статус перезаписи AOF, время последнего сохранения и индикаторы задержек fsync. Сочетайте это с метриками хоста: задержка диска, свободное дисковое пространство, запас памяти и события OOM ядра. Если BGSAVE терпит неудачу часами, и никто не замечает, конфигурация Redis может выглядеть безопасной, в то время как фактическая точка восстановления становится все старше и старше.

Используйте репликацию или Sentinel для доступности, а не как единственное резервное копирование

Реплики, Redis Sentinel и Redis Cluster помогают с доступностью. Они не решают автоматически все проблемы потери данных. Плохая запись, случайное удаление или ошибка приложения могут быстро реплицироваться. Отказоустойчивость также может повысить реплику, которая пропустила недавние записи, если существует задержка репликации. Включайте персистентность, резервное копирование и тесты восстановления в проект.

Практичная настройка для многих команд — AOF с appendfsync everysec, RDB-снимки с разумной периодичностью, внешние резервные копии, мониторинг сбоев персистентности и проверенный сценарий восстановления. Redis может быть надежным в такой форме, но только если вы относитесь к персистентности как к операционной системе, а не как к галочке.