Как сделать резервную копию файлов Redis Sever RDB и AOF для восстановления, чтобы обеспечить минимальную потерю данных?
Цель:
Я пытаюсь делать резервные копии как dump.rdb каждый раз X, так и appendonly.aof каждый раз Y, чтобы, если файлы были повреждены по какой-либо причине (или даже просто в файле AOF appendonly.aof), я мог восстановить свои данные из дампа. Снимок rdb.backup, а затем все остальное изменилось с последней копией appendonly.aof.backup, которую я имею.
Ситуация:
Я делаю резервную копию dump.rdb каждые 5 минут, а резервную копию appendonly.aof каждую 1 секунду.
Проблемы:
1) Так как dump.rdb записывается в фоновом режиме во временный файл дочерним процессом - что произойдет с изменениями ключа, которые происходят, когда дочерний процесс создает новый образ? Я знаю, что файл AOF будет продолжать добавляться независимо от фоновой записи, но содержит ли новый файл dump.rdb изменения ключа?
2) Если dump.rdb НЕ содержит изменений ключа, есть ли способ выяснить точную точку, где дочерний процесс разветвляется? Таким образом, я могу отслеживать точку, после которой в файле AOF будет самая актуальная информация.
Спасибо!
1 ответ
Обычно люди используют либо RDB, либо AOF как постоянную стратегию. Наличие обоих из них довольно дорого. Запуск дампа каждые 5 минут и копирование файла aof каждую секунду звучит ужасно часто. За исключением случаев, когда экземпляры Redis хранят только небольшое количество данных, вы, скорее всего, убьете подсистему ввода / вывода вашего устройства.
Теперь по поводу ваших вопросов:
1) Семантика механизма RDB
Механизм дампа использует механизм копирования при записи, реализованный в современных ядрах ОС при обработке клонов / вилок. Когда форк закончен, система просто создает фоновый процесс, копируя таблицу страниц. Сами страницы распределяются между двумя процессами. Если операция записи выполняется на странице процессом Redis, ОС будет прозрачно дублировать страницу (так что экземпляр Redis будет иметь свою собственную версию, а фоновый процесс - предыдущую версию). Таким образом, фоновый процесс гарантирует, что структуры памяти поддерживаются постоянными (и, следовательно, согласованными).
В результате любая операция записи, запущенная после того, как разветвление не будет принято в дамп. Дамп представляет собой согласованный снимок, сделанный во время разветвления.
2) Отслеживание точки развилки
Вы можете оценить временную метку разветвления, запустив команду сохраняемости INFO и вычислив rdb_last_save_time - rdb_last_bgsave_time_sec, но она не очень точна (только вторая).
Чтобы быть немного более точным (в миллисекундах), вы можете проанализировать файл журнала Redis, чтобы извлечь следующие строки:
[3813] 11 Apr 10:59:23.132 * Background saving started by pid 3816
Вам нужен хотя бы уровень журнала уведомлений, чтобы увидеть эти строки.
Насколько я знаю, нет никакого способа соотнести конкретную запись в AOF с операцией разветвления RDB (то есть невозможно быть на 100% точной).