2026 Redis 8.0: что делать при сбое переписывания AOF? Сначала проверьте диск и цепочку восстановления

В Redis 8.0 переписывание AOF завершается ошибкой, появляется предупреждение о диске или непонятно, можно ли восстановить данные.

Самое быстрое безопасное действие: не удаляйте AOF и не перезапускайте Redis наугад. Сначала проверьте состояние сохранения, место и состав файлов, затем скопируйте набор и проверьте восстановление в изолированной среде. По состоянию на 4 ноября 2026 года поддержка Redis 8.0 должна завершиться 1 декабря 2026 года — проверьте план обновления отдельно от плана резервирования (официальная страница управления версиями Redis).

Эта инструкция для DBA, отвечающих за сохранение данных в Redis 8.0.
Она также пригодится инженерам приложения и платформы, если сработало предупреждение о диске или переписывание остановилось.
Техническим руководителям она поможет включить в план размещения объём хранилища, внешнюю резервную копию и тест восстановления.

Сначала разделите симптомы, а не назначайте виновником диск

Переписывание AOF — фоновая операция, которая создаёт обновлённое представление журнала; при этом Redis продолжает принимать команды записи. Поэтому старая и создаваемая версии файлов могут одновременно занимать место, а новые записи во время операции должны учитываться. В Redis с многофайловым AOF для понимания состава важны манифест, базовый файл и инкрементальные файлы — одного найденного файла с расширением AOF недостаточно, чтобы судить о полной цепочке (документация Redis о сохранении данных и многофайловом AOF).

В первую очередь определите, к какой группе относится наблюдаемая проблема:

• Ошибка выделения места или записи. Проверяйте свободные блоки, inode, состояние файловой системы и сообщения ядра о вводе-выводе.
• Переписывание завершилось неуспешно. Сопоставьте поля INFO persistence с логами и состоянием процесса. Само сообщение об ошибке не показывает, какой компонент был первопричиной.
• Операция долго не меняет состояние. Проверьте, продолжается ли фоновая работа, есть ли нагрузка на диск и нет ли конкурирующего процесса. Длительность без контекста не доказывает зависание.
• После сбоя сомнителен результат загрузки. Не путайте успешный запуск Redis с подтверждением корректности прикладных данных.

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

Для первичной фиксации состояния выполните запросы с теми параметрами подключения, которые приняты у вас:

redis-cli INFO persistence
redis-cli CONFIG GET dir appendonly appenddirname

В выводе INFO persistence обратите внимание на aof_rewrite_in_progress, aof_last_bgrewrite_status, aof_last_write_status, aof_current_size и aof_base_size. Названия и назначение полей описаны в справочнике команды INFO. Зафиксируйте результат и время получения, не меняя настройки. CONFIG GET помогает сверить каталог и параметры AOF; команда не заменяет проверку фактического содержимого файлов. Доступность и синтаксис параметров сверяйте с конфигурацией именно вашей сборки.

Сопоставьте место, inode и состояние хранилища

Проверяйте файловую систему, на которой расположен каталог Redis, а не только общий объём диска. Для этого подставьте каталог из конфигурации:

df -h /путь/к/каталогу-redis
df -i /путь/к/каталогу-redis
findmnt -T /путь/к/каталогу-redis
du -sh /путь/к/каталогу-redis

df -h показывает доступные блоки в удобном для чтения виде, а df -i — использование inode; краткое описание назначения df приводит руководство GNU Coreutils. findmnt помогает понять, какое монтирование обслуживает каталог. Сверьте результаты с тем, где фактически лежат манифест и файлы AOF. Если путь находится на отдельном разделе или смонтированной файловой системе, свободное место на другом разделе не поможет завершить запись.

Не заменяйте проверку приблизительным правилом вроде «для переписывания всегда нужно вдвое больше места». Потребность зависит от текущего набора, объёма данных, поступающих записей и поведения конкретного запуска. Сначала оцените размер имеющихся файлов и доступное пространство на нужной файловой системе; во время переписывания оставьте запас на создаваемый файл и текущие записи. Если данных для оценки нет, считайте ситуацию неразрешённой, пока не проверите копию на подходящем объёме хранилища.

Когда места мало, безопаснее рассматривать очистку только тех временных или посторонних файлов, необходимость которых подтверждена их владельцем. Другой вариант — добавить доступное хранилище или перенести нагрузку после проверки процедуры. Не удаляйте файлы AOF, манифест или «старую версию»: пока не проверена структура набора и состояние процесса, вы не знаете, какие элементы нужны для запуска и восстановления.

Отличите задержку от отказа фоновой операции

Если место и монтирование выглядят штатно, повторно снимите INFO persistence и сравните его с сохранённым выводом. aof_rewrite_in_progress показывает, идёт ли переписывание; aof_last_bgrewrite_status и aof_last_write_status помогают понять, как завершилась последняя операция и были ли проблемы записи. Смысл этих полей и формат ответа описаны в документации Redis по INFO.

Для диагностики сопоставляйте данные из нескольких источников, а не делайте вывод по одному флагу:

• журнал Redis: сообщение о запуске и завершении переписывания, записи или ошибке;
• состояние процесса: существует ли дочерний процесс, выполняющий фоновую работу;
• система: присутствуют ли ошибки файловой системы, нехватка памяти или конкуренция за ввод-вывод;
• динамика: меняется ли состояние между повторными проверками.

BGREWRITEAOF запускает переписывание, если его можно выполнить в текущем состоянии, но повторная команда не является универсальным способом «разблокировать» операцию. Перед ручным запуском прочитайте описание BGREWRITEAOF и выясните, не идёт ли уже фоновая работа. Не запускайте команду многократно и не меняйте параметры записи, пока не сохранены исходные логи и вывод состояния.

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

Сохраните целостный набор до любой попытки ремонта

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

Сопоставьте варианты действий по риску:

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

redis-check-aof используйте только после определения версии, типа файла и ожидаемого действия утилиты. Сначала проверьте справку именно установленной сборки и направьте инструмент на копию. Если документация для вашего формата не подтверждает, какой файл проверять, не экспериментируйте с манифестом и инкрементальными частями вручную: остановитесь и проверьте процедуру на отдельной копии. Опция исправления может привести к потере повреждённого хвоста; сохраните исходник и зафиксируйте, какие изменения были выполнены. Успешный код завершения не подтверждает, что бизнес-данные целы.

Проверьте восстановление отдельно от производства

После получения копии запускайте тестовый экземпляр в изолированной среде с тем же основным процессом восстановления, который вы планируете использовать для аварийного возврата. Отдельный экземпляр снижает риск случайно перезаписать исходные данные, но его результат всё равно нужно оценивать по содержимому и требованиям приложения.

Порядок проверки:

1. Сверьте, что в копии присутствует манифест и все указанные им файлы; сохраните сведения о том, откуда и когда получена копия.
2. Используйте подходящую версию Redis и зафиксируйте параметры запуска. Не меняйте параметры сохранения ради того, чтобы тестовый запуск «прошёл».
3. Запустите экземпляр без подключения производственных клиентов и наблюдайте за журналом восстановления.
4. Проверьте ключевые типы данных, критичные значения, сроки действия и прикладные ограничения. Если приложение использует потоки, отдельно проверьте ожидаемую структуру и обработанные позиции.
5. Сопоставьте результат с контрольной точкой резервной копии. Разницу оценивайте с учётом времени её создания и ожидаемого объёма последующих записей.

AOF и RDB — разные механизмы сохранения; исправный путь загрузки одного формата не доказывает исправность другого. Уточните, какой источник фактически будет использоваться при запуске, и проверьте оба сценария, если в вашем плане восстановления предусмотрены оба. Документация Redis по сохранению данных и взаимодействию AOF с RDB описывает базовые различия. До успешной проверки не заменяйте рабочие файлы и не сообщайте команде, что данные восстановлены полностью.

Условия перехода от диагностики к восстановлению

Выберите действие по результатам проверок, а не по одному сообщению об ошибке:

• Если свободное место или inode исчерпаны, то сначала сохраните набор и устраните подтверждённый дефицит ресурса; иначе переходите к проверке процесса и журналов.
• Если манифест и все связанные файлы скопированы согласованно, то запускайте восстановление только на копии; иначе не применяйте проверку с исправлением и повторите резервное копирование.
• Если тестовый экземпляр запускается и проходит проверку прикладных инвариантов, то документируйте последовательность возврата и допустимую точку данных; иначе сохраняйте копию и исследуйте логи, не подменяя производственный набор.
• Если первопричина подтверждена и исправлена, то повторите наблюдение после восстановления сервиса; иначе не трактуйте удачный запуск как устранение риска.
• Если Redis 8.0 остаётся в эксплуатации, то запланируйте проверку поддерживаемой версии до указанной даты завершения поддержки; в любом случае оставьте резервирование и восстановление самостоятельными мерами.

FAQ о диске, копировании и проверке

Какие сведения собрать перед изменениями?

Сохраните вывод INFO persistence, конфигурационные значения каталога и параметров AOF, журналы Redis и результаты проверки файловой системы. Зафиксируйте состав каталога и связь файлов с манифестом. Не меняйте настройки до снимка исходного состояния: иначе при сравнении будет сложнее отделить первоначальную проблему от последствий диагностических действий.

Почему свободного места на диске может быть достаточно, а переписывание всё равно не идёт?

Проверьте inode и фактическое монтирование каталога, затем ищите ошибки записи, ограничения файловой системы и конкурирующую нагрузку. Успешный вывод df -h не подтверждает, что процесс Redis может записать данные. Сопоставляйте системное состояние с полями INFO и журналами; если причина не подтверждена, сохраните наблюдения и не переносите диагноз из чужого случая на свою систему.

Можно ли считать AOF исправным, если Redis запускается?

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

Сервер и резервирование — разные решения

Сбой AOF нужно лечить по результатам диагностики; смена сервера сама по себе не исправляет файл и не гарантирует сохранность данных. Но если текущий вариант размещения не даёт предсказуемого доступа к хранилищу, ограничивает выбор дисковой схемы или оставляет вас с неясной ответственностью за копии, сравните его с арендой выделенного сервера. У общей виртуальной машины возможны конкуренция за ресурсы и ограничения на управление дисковой конфигурацией; в облачной модели также проверьте, как тарифицируются хранилище и операции ввода-вывода. Эти особенности зависят от конкретного предложения — сверяйте условия, а не переносите их на все сервисы.

При этом выделенный сервер не заменяет резервную копию. Если в выбранной конфигурации нет аппаратного RAID, спланируйте программное зеркалирование или репликацию и храните резервную копию вне основного сервера. Для планирования дисков можно сверить материал о выборе памяти и диска, а границы ответственности за размещённую службу — в описании условий сервиса.

Если вам важны независимое выделенное оборудование и возможность отдельно спланировать хранение и восстановление, сравните эти условия с предложениями аренды AMD-серверов OSFP Cloud: проверьте актуальные параметры и стоимость на странице OSFP Cloud. Выбирайте такой вариант ради контролируемой инфраструктуры, а надёжность данных подтверждайте внешней копией и регулярной проверкой восстановления.

Вопросы

С чего начать, если переписывание AOF в Redis 8.0 завершилось ошибкой?

Сначала сохраните состояние, не удаляя и не переименовывая рабочие файлы. Проверьте INFO persistence, свободное место, inode и состояние монтирования именно для файловой системы с каталогом Redis. Затем выясните, используется ли многофайловый AOF и какие файлы указаны в его манифесте. Только после копирования набора и проверки версии инструмента переходите к восстановлению в изолированной среде.

Что делать, если во время переписывания AOF заканчивается место на диске?

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

Как скопировать многофайловый AOF из Redis 7 или более новой версии?

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

Как убедиться, что исправленный AOF действительно восстанавливает данные?

Успешное завершение проверки файла само по себе не подтверждает полноту бизнес-данных. Запустите копию в изолированном экземпляре, проверьте журналы старта, типы ключей, критичные значения, сроки действия и прикладные инварианты, включая данные потоков, если приложение их использует. Сравнивайте состояние с резервной копией подходящего времени и не подменяйте производственные файлы, пока восстановление не прошло ваши проверки.