Как обеспечить возможность восстановления данных после того, как Redis зависнет, а затем перезапустится?

Redis

Аранжировка из курса Hushan Code Farm.

Значение механизма сохраняемости redis для аварийного восстановления в производственной среде

Содержание курса

1. Что происходит, когда происходит сбой

Redis внезапно зависает, процесс умирает или машина, на которой он находится, исчезает, что приводит к поломке Redis, что приведет к потере важных данных кэша. Это может привести к простою mysql, а восстановление данных Redis также усложняется.

2. Как бороться с неудачами

Многие студенты читали некоторые материалы и книги по Redis и, конечно же, могли смотреть некоторые видеокурсы по Redis.

Вся информация на самом деле объясняет постоянство redis, но есть проблема: до сих пор я не видел, чтобы кто-нибудь очень подробно объяснял постоянство redis.

Постоянство redis, RDB, AOF, различия, каковы их характеристики и какие сценарии подходят для них

redis的企业级的持久化方案是什么,是用来跟哪些企业级的场景结合起来使用的? ? ?

Redis постоянный смысл, что выздоровление

Например, если вы развертываете Redis в качестве кеша, конечно, вы также можете сохранить некоторые более важные данные

Без постоянства, когда Redis столкнется с катастрофическим сбоем, все данные будут потеряны.

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

Графический анализ принципов работы механизмов сохранения Redis, RDB и AOF.

Содержание курса

1 Введение, RDB и два вида механизма сохраняемости AOF 2, преимущества механизма сохранения RDB 3, недостатки механизма сохранения RDB 4, AOF длительное преимущество механизма 5, недостатки механизма сохранения AOF 6, RDB и AOF, в конце концов, как выбрать

Мы уже знаем, что для Redis-архитектуры корпоративного уровня постоянство непреодолимо.

Кластерная архитектура Redis корпоративного уровня: большие объемы данных, высокий уровень параллелизма, высокая доступность

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

Например, если Redis полностью зависает, а затем Redis недоступен, вам нужно сделать Redis доступным как можно скорее.

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

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

MySQL висит, вы не можете найти данные для восстановления для Redis, где данные Redis? От mysql. . .

Конкретная полная сцена для лавины кеша, а также решения для корпоративных классов, чтобы поговорить

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

Постоянство Redis связано с высокой доступностью, что объясняется в архитектуре Redis на уровне предприятия.

постоянство Redis: RDB, AOF


1. Внедрение механизмов сохранения RDB и AOF

Механизм сохранения RDB, который выполняет периодическое сохранение данных в Redis.

Механизм AOF использует каждую команду записи как журнал и записывает ее в файл журнала в режиме только добавления.При перезапуске Redis весь набор данных можно восстановить, воспроизведя команды записи в журнале AOF.

Если мы хотим использовать только в качестве чистой памяти кэш для использования, вы можете отключить весь механизм постоянства RDB и AOF

Через RDB или AOF данные в памяти Redis могут быть сохранены на диске, а затем данные могут быть скопированы в другие места, такие как Alibaba Cloud, облачные сервисы.

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

Если механизмы сохранения RDB и AOF используются одновременно, при перезапуске Redis для перестроения данных будет использоваться AOF, поскольку данные в AOF являются более полными.


2. Преимущества механизма сохраняемости RDB

(1) RDB будет генерировать несколько файлов данных, каждый из которых представляет данные Redis в определенный момент.Этот метод нескольких файлов данных очень подходит для холодного резервного копирования, и этот полный файл данных можно отправить.Перейдите на какой-нибудь удаленный безопасный хранилище, такое как облачный сервис Amazon S3 или распределенное хранилище ODPS от Alibaba Cloud в Китае, и регулярно выполнять резервное копирование данных в Redis с заранее определенной стратегией резервного копирования.

  • RDB готовится генерировать несколько файлов, каждый из которых представляет полный снимок данных в определенный момент
  • AOF делает холодный резерв, только один файл, но можно через равные промежутки времени копировать файл

(2) RDB очень мало влияет на службы чтения и записи, предоставляемые Redis, что может поддерживать высокую производительность Redis, поскольку основному процессу Redis нужно только разветвить дочерний процесс и позволить дочернему процессу выполнять операции ввода-вывода на диске для RDB. упорство.

Каждый раз, когда RDB записывает, он записывает непосредственно в память Redis и записывает данные на диск только в определенное время.

AOF, приходится каждый раз записывать файлы, хотя и можно быстро записать в кеш ос, но все же есть определенные накладные расходы по времени, скорость точно чуть медленнее, чем RDB

(3) По сравнению с механизмом сохранения AOF быстрее перезапустить и восстановить процесс Redis непосредственно на основе файла данных RDB.

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

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

В сочетании с перечисленными выше преимуществами RDB особенно подходит для холодного резервного копирования.


3. Недостатки механизма сохранения RDB

(1) Если вы хотите потерять как можно меньше данных при сбое redis, тогда RDB не так хорош, как AOF. Вообще говоря, файлы моментальных снимков данных RDB генерируются каждые 5 минут или дольше.В настоящее время необходимо признать, что после сбоя процесса redis данные за последние 5 минут будут потеряны.

(2) Каждый раз, когда RDB выполняет генерацию файла данных моментального снимка RDB в дочернем процессе fork, если файл данных особенно велик, это может привести к приостановке службы, предоставляемой клиенту, на несколько миллисекунд или даже несколько секунд.


4. Преимущества механизма сохраняемости AOF

(1) AOF может лучше защитить данные от потери.Как правило, AOF выполняет операцию fsync через фоновый поток каждую 1 секунду, и данные будут потеряны на срок до 1 секунды.

(2) Файлы журналов AOF записываются в режиме только добавления, поэтому накладные расходы на адресацию диска отсутствуют, производительность записи очень высока, и файл нелегко повредить, даже если конец файла поврежден, это легко ремонтировать

(3) Даже если файл журнала AOF слишком велик, выполняется фоновая операция перезаписи, которая не повлияет на чтение и запись клиента. Потому что при перезаписи лога инструкции в нем будут сжаты для создания минимального лога, который нужно восстановить. При создании нового файла журнала старый файл журнала по-прежнему записывается как обычно. Когда новый объединенный файл журнала будет готов, можно будет обменяться новыми и старыми файлами журнала.

(4) Команда AOF файлов журналов записывается очень читабельно, эта функция идеально подходит для аварийного восстановления случайно удаленного катастрофа. Например, кто-то случайно с командой Plashall для очистки всех данных, до тех пор, пока на этот раз на этот раз задержка перезапись не произошла, то вы можете сразу скопировать файлы AOF, последнюю команду makeall для удаления, а затем поставить файл обратно AOF, вы можете Механизм восстановления автоматически восстановить все данные


5. Недостатки механизма сохранения AOF

(1) Для одних и тех же данных файлы журнала AOF обычно больше, чем файлы моментальных снимков данных RDB.

(2) После включения AOF поддерживаемое количество запросов в секунду при записи будет ниже, чем количество запросов в секунду при записи, поддерживаемое RDB, поскольку AOF обычно настроен на синхронизацию файлов журнала один раз в секунду.Конечно, fsync один раз в секунду, производительность по-прежнему очень высокий

(3) Раньше в AOF была ошибка, то есть при восстановлении данных через лог, записанный AOF, точно такие же данные не восстанавливались. Таким образом, более сложный метод, основанный на журнале команд/объединении/воспроизведении, такой как AOF, более хрупок и подвержен ошибкам, чем метод, основанный на RDB, который каждый раз сохраняет полный файл моментального снимка данных. Тем не менее, AOF предназначен для предотвращения ошибок, вызванных процессом перезаписи, поэтому каждая перезапись основана не на старом журнале инструкций для слияния, а на данных в памяти в то время для перестроения инструкции, поэтому надежность будет намного лучше. .


6. Как выбрать между RDB и AOF

(1) Не используйте только RDB, потому что это приведет к потере большого количества данных.

(2) Не используйте только AOF, потому что есть две проблемы: во-первых, если вы используете AOF для холодного резервного копирования, без RDB для холодного резервного копирования, скорость восстановления выше, во-вторых, RDB каждый раз просто и грубо генерирует моментальные снимки данных. , который является более надежным и позволяет избежать ошибок в сложном механизме резервного копирования и восстановления AOF.

(3) Комплексное использование механизмов сохранения AOF и RDB, AOF используется для обеспечения того, чтобы данные не были потеряны, как первый выбор для восстановления данных; RDB используется для различных степеней холодного резервного копирования, даже если файлы AOF потеряны или повреждены и недоступен В то же время вы также можете использовать RDB для быстрого восстановления данных