Поделиться через


Настройка сохранения данных (предварительный просмотр) для управляемого экземпляра Redis в Azure

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

Это важно

Постоянное хранение служит для того, чтобы обеспечить устойчивость на случай непредвиденных сбоев узлов Redis, однако это не функция резервного копирования данных или восстановления до состояния на определенный момент (PITR). Если поврежденные данные записываются в экземпляр Redis, эти данные также будут сохранены. Для создания резервных копий экземпляра Redis воспользуйтесь функцией экспорта.

Область доступности

Уровень Оптимизированный для памяти, сбалансированный, оптимизированный для вычислений Оптимизированный для флеш-технологий
В наличии Да (предварительная версия) Да (предварительная версия)

Типы сохраняемости данных в Redis

Существует два варианта сохранения с помощью Управляемого Redis в Azure: формат базы данных Redis (RDB) и формат "Добавить только файл " (AOF):

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

Это важно

Функции постоянного хранения Redis под управлением Azure предназначены для автоматического восстановления данных в том же кэше после потери данных. Файлы данных RDB/AOF на постоянном хранения недоступны пользователям и не импортируются в новый или существующий кэш. Для перемещения данных между кэшами используйте функцию импорта и экспорта. Дополнительные сведения см. в статье Импорт и экспорт данных в Redis под управлением Azure.

Чтобы создать резервные копии данных, которые можно добавить в новый кэш, можно создавать автоматические скрипты с помощью PowerShell или Azure CLI, которые периодически экспортируют данные.

Предварительные требования и ограничения

Функции сохраняемости предназначены для восстановления данных в том же кэше после потери данных.

  • Сохраненные файлы данных RDB/AOF не могут быть импортированы в новый или существующий кэш. Вместо этого используйте функцию Импорт/экспорт.
  • Кэши, использующие активную георепликацию, не поддерживают постоянное хранение.
  • Управляемый диск с сохраненными файлами данных шифруется с помощью управляемых ключей Microsoft (MMK) по умолчанию, но также можно использовать управляемые клиентом ключи (CMK). Дополнительные сведения см. в статье Управление шифрованием данных.

Настройка сохраняемости данных (предварительная версия) с помощью портала Azure

  1. Войдите в портал Azure и следуйте инструкциям в кратком руководстве по Управляемому Redis в Azure.

  2. При достижении вкладки "Дополнительно" выберите параметры RDB или AOF в разделе "Сохраняемость данных".

    Снимок экрана, на котором показана вкладка

  3. Чтобы включить сохраняемость RDB, щелкните RDB и настройте параметры.

    Настройки Рекомендуемое значение Описание
    Частота резервного копирования Используйте раскрывающийся список и выберите интервал резервного копирования. Варианты включают 60 минут, 6 часов и 12 часов. Отсчет этого интервала начинается после успешного завершения предыдущей операции резервного копирования. По истечении этого интервала начинается новое резервное копирование.
  4. Чтобы включить сохраняемость AOF, выберите AOF. Доступен только один параметр частоты резервного копирования.

  5. Завершите создание кэша, выполнив остальные инструкции из краткого руководства по Управляемому Redis в Azure.

Замечание

Сохраняемость можно добавить в ранее созданный экземпляр Azure Managed Redis в любое время, перейдя к дополнительным параметрам в меню ресурсов.

Настройка сохраняемости данных (предварительная версия) с помощью PowerShell и Azure CLI

Использование PowerShell

Команду New-AzRedisEnterpriseCache можно использовать для создания нового экземпляра Управляемого Redis Azure с помощью сохраняемости данных. Используйте параметры RdbPersistenceEnabled, RdbPersistenceFrequency, AofPersistenceEnabled и AofPersistenceFrequency для настройки конфигурации сохранения. В этом примере создается новый экземпляр Balanced B10 с использованием сохраняемости RDB с одной часовой частотой:

New-AzRedisEnterpriseCache -Name "MyCache" -ResourceGroupName "MyGroup" -Location "West US" -Sku "Balanced_B10" -RdbPersistenceEnabled -RdbPersistenceFrequency "1h"

Существующие кэши можно обновить с помощью команды Update-AzRedisEnterpriseCacheDatabase . В этом примере к существующему экземпляру добавляется сохраняемость RDB с частотой 12 часов:

Update-AzRedisEnterpriseCacheDatabase -Name "MyCache" -ResourceGroupName "MyGroup" -RdbPersistenceEnabled -RdbPersistenceFrequency "12h"

Использование Azure CLI

Команду az redisenterprise create можно использовать для создания нового экземпляра Управляемого Redis Azure с помощью сохраняемости данных. Используйте параметры rdb-enabled, rdb-frequency, aof-enabled и aof-frequency для настройки конфигурации сохранения. В этом примере создается новый экземпляр Balanced B10 с использованием сохраняемости RDB с одной часовой частотой:

az redisenterprise create --cluster-name "cache1" --resource-group "rg1" --location "East US" --sku "Balanced_B10" --persistence rdb-enabled=true rdb-frequency="1h" 

Существующие кэши можно обновить с помощью команды az redisenterprise database update . В этом примере к существующему экземпляру кэша добавляется сохраняемость RDB с частотой 12 часов:

az redisenterprise database update --cluster-name "cache1" --resource-group "rg1" --persistence rdb-enabled=true rdb-frequency="12h" 

Управление шифрованием данных

Поскольку устойчивость Redis создает данные в состоянии покоя, шифрование этих данных представляет собой значительную заботу для многих пользователей. В Управляемом Redis azure данные хранятся на управляемом диске, подключенном к экземпляру кэша. По умолчанию диск с данными сохраняемости и диск ОС шифруются с помощью ключей, управляемых Корпорацией Майкрософт. Ключ, управляемый клиентом (CMK), также можно использовать для управления шифрованием данных. Инструкции см. в разделе "Шифрование в Управляемом Redis Azure".

Часто задаваемые вопросы о постоянстве

Следующий список содержит ответы на часто задаваемые вопросы о постоянном хранении в Redis под управлением Azure.

Сохраняемость RDB

Сохраняемость AOF

Можно ли включить постоянное хранение для ранее созданного кэша?

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

Можно ли одновременно активировать сохраняемость AOF и RDB?

Нет, вы можете включить RDB или AOF, но не оба одновременно.

Как сохраняемость работает с георепликацией?

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

Какую модель сохраняемости следует выбрать?

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

Дополнительные сведения о производительности при использовании постоянного хранения AOF см. в разделе Влияет ли постоянное хранение AOF на пропускную способность, задержку или производительность кэша?

Влияет ли сохраняемость AOF на пропускную способность, задержку или производительность кэша?

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

Что произойдет, если выполнено масштабирование на другой размер, а резервная копия, созданная до этой операции, восстановлена?

Для сохраняемости как RDB, так и AOF:

  • Если было выполнено масштабирование до большего размера, это не окажет никакого влияния.
  • Если выполнено масштабирование до меньшего размера, и вам не хватает места для хранения всех данных из последней резервной копии, то при восстановлении ключи будут исключены. Как правило, ключи удаляются согласно политике allkeys-lru.

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

Плата за управляемое хранилище дисков не взимается. Она включена в цену.

Можно ли изменить частоту резервного копирования RDB после создания кэша?

Да, частоту резервного копирования для постоянного хранения RDB можно изменить с помощью Azure Portal, CLI или PowerShell.

Почему при установленной частоте резервного копирования RDB в 60 минут между созданием резервных копий проходит больше времени?

Интервал резервного копирования сохраняемости RDB не начинается, пока не завершится процесс предыдущего резервного копирования. Если интервал резервного копирования составляет 60 минут и на процесс резервного копирования уходит 15 минут, то следующее резервное копирование начнется не ранее чем через 75 минут после начала предыдущего резервного копирования.

Что происходит со старыми резервными копиями RDB при создании другой?

Все резервные копии сохраняемости RDB, за исключением последней, автоматически удаляются. Это удаление может происходить не сразу, но старые резервные копии не хранятся в течение неограниченного периода времени.

Что такое перезапись и как она влияет на кэш?

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

Чего ожидать при масштабировании кэша с включенным AOF?

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

Дополнительные сведения см. в разделе Что произойдет, если выполнено масштабирование до другого размера, а резервная копия была создана до этой операции?

Дальнейшие шаги