Настройка постоянного хранения данных для экземпляра 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
Войдите в портал Azure и следуйте инструкциям в кратком руководстве по Управляемому Redis в Azure.
При достижении вкладки "Дополнительно" выберите параметры RDB или AOF в разделе "Сохраняемость данных".
Чтобы включить сохраняемость RDB, щелкните RDB и настройте параметры.
Параметр Предлагаемое значение Description Частота резервного копирования Используйте раскрывающийся список и выберите интервал резервного копирования. Варианты включают 60 минут, 6 часов и 12 часов. Отсчет этого интервала начинается после успешного завершения предыдущей операции резервного копирования. По истечении этого интервала начинается новое резервное копирование. Чтобы включить сохраняемость AOF, выберите AOF. Доступен только один параметр частоты резервного копирования.
Завершите создание кэша, выполнив остальные инструкции из краткого руководства по Управляемому Redis в Azure.
Примечание.
Сохраняемость можно добавить в ранее созданный экземпляр Azure Managed Redis в любое время, перейдя к дополнительным параметрам в меню ресурсов.
Настройка сохраняемости данных с помощью PowerShell и Azure CLI
Использование PowerShell
Команду New-AzRedisEnterpriseCache можно использовать для создания нового экземпляра Управляемого Redis Azure с помощью сохраняемости данных.
RdbPersistenceEnabledИспользуйте параметры и AofPersistenceEnabledRdbPersistenceFrequencyAofPersistenceFrequency параметры, чтобы настроить настройку сохраняемости. В этом примере создается новый экземпляр 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Используйте параметры и aof-enabledrdb-frequencyaof-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.
- Можно ли включить постоянное хранение для ранее созданного кэша?
- Можно ли одновременно активировать сохраняемость AOF и RDB?
- Как сохраняемость работает с георепликацией?
- Какую модель сохраняемости следует выбрать?
- Что произойдет, если выполнено масштабирование до другого размера, а резервная копия была создана до этой операции?
- Будет ли начисляться плата за управляемый диск, используемый для постоянного хранения данных?
Сохраняемость RDB
- Можно ли изменить частоту резервного копирования RDB после создания кэша?
- Почему при установленной частоте резервного копирования RDB в 60 минут между созданием резервных копий проходит больше времени?
- Что происходит со старыми резервными копиями RDB при создании другой?
Сохраняемость AOF
- Влияет ли сохраняемость AOF на пропускную способность, задержку или производительность кэша?
- Что такое перезапись и как она влияет на кэш?
- Что следует ожидать при масштабировании кэша с включенной сохраняемостью AOF?
Можно ли включить постоянное хранение для ранее созданного кэша?
Да, вы можете настроить постоянное хранение как при создании кэша, так и в уже существующих экземплярах Redis под управлением Azure.
Можно ли одновременно активировать сохраняемость AOF и RDB?
Нет. Вы можете включить только сохраняемость RDB или AOF.
Как сохраняемость работает с георепликацией?
Если включить постоянное хранение данных, то для кэша невозможно будет включить георепликацию. Дело в том, что в случае регионального сбоя активная георепликация обеспечивает более высокую устойчивость, чем постоянное хранение данных. Если вам нужно экспортировать копию данных в качестве резервной копии, используйте функцию экспорта.
Какую модель сохраняемости следует выбрать?
Сохраняемость AOF позволяет сохранять каждую операцию записи в журнал, что значительное влияет на пропускную способность. Для сравнения, постоянное хранение RDB обеспечивает сохранение резервных копий по настроенному интервалу резервного копирования с минимальным влиянием на производительность. Выберите сохраняемость AOF, если основная цель заключается в минимизации потери данных, а уменьшение пропускной способности кэша не является проблемой. Используйте сохраняемость RDB, если вы хотите поддерживать оптимальную пропускную способность в кэше, но при этом необходим механизм восстановления данных.
- Узнайте больше о преимуществах и недостатках сохраняемости RDB.
- Узнайте больше о преимуществах и недостатках сохраняемости AOF.
Дополнительные сведения о производительности при использовании постоянного хранения 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 во время масштабирования увеличивается в размере, следует ожидать, что операция масштабирования займет больше времени, чем обычно, так как после завершения масштабирования файл перезагружается.
Дополнительные сведения см. в разделе Что произойдет, если выполнено масштабирование до другого размера, а резервная копия была создана до этой операции?