How to configure data persistence for a Premium Azure Redis Cache

Azure Redis Cache has different cache offerings which provide flexibility in the choice of cache size and features, including Premium tier features such as clustering, persistence, and virtual network support. This article describes how to configure persistence in a premium Azure Redis Cache instance.

For information on other premium cache features, see Introduction to the Azure Redis Cache Premium tier.

What is data persistence?

Redis persistence allows you to persist data stored in Redis. You can also take snapshots and back up the data, which you can load in case of a hardware failure. This is a huge advantage over Basic or Standard tier where all the data is stored in memory and there can be potential data loss in case of a failure where Cache nodes are down.

Azure Redis Cache offers Redis persistence using the following models:

  • RDB persistence - When RDB (Redis database) persistence is configured, Azure Redis Cache persists a snapshot of the Redis cache in a Redis binary format to disk based on a configurable backup frequency. If a catastrophic event occurs that disables both the primary and replica cache, the cache is reconstructed using the most recent snapshot. Learn more about the advantages and disadvantages of RDB persistence.
  • AOF persistence - When AOF (Append only file) persistence is configured, Azure Redis Cache saves every write operation to a log that is saved at least once per second into an Azure Storage account. If a catastrophic event occurs that disables both the primary and replica cache, the cache is reconstructed using the stored write operations. Learn more about the advantages and disadvantages of AOF persistence.

Persistence is configured from the New Redis Cache blade during cache creation and on the Resource menu for existing premium caches.

To create a premium cache, sign-in to the Azure portal and click New > Databases > Redis Cache.

Create cache

Note

In addition to creating caches in the Azure portal, you can also create them using Resource Manager templates, PowerShell, or Azure CLI. For more information about creating an Azure Redis Cache, see Create a cache.

To configure premium features, first select one of the premium pricing tiers in the Pricing tier drop-down list. For more information about each pricing tier, click View full pricing details and select a pricing tier from the Choose your pricing tier blade.

Choose your pricing tier

Once a premium pricing tier is selected, click Redis persistence.

Redis persistence

The steps in the next section describe how to configure Redis persistence on your new premium cache. Once Redis persistence is configured, click Create to create your new premium cache with Redis persistence.

Enable Redis persistence

Redis persistence is enabled on the Redis data persistence blade by choosing either RDB or AOF persistence. For new caches, this blade is accessed during the cache creation process, as described in the previous section. For existing caches, the Redis data persistence blade is accessed from the Resource menu for your cache.

Redis settings

Configure RDB persistence

To enable RDB persistence, click RDB. To disable RDB persistence on a previously enabled premium cache, click Disabled.

Redis RDB persistence

To configure the backup interval, select a Backup Frequency from the drop-down list. Choices include 15 Minutes, 30 minutes, 60 minutes, 6 hours, 12 hours, and 24 hours. This interval starts counting down after the previous backup operation successfully completes and when it elapses a new backup is initiated.

Click Storage Account to select the storage account to use, and choose either the Primary key or Secondary key to use from the Storage Key drop-down. You must choose a storage account in the same region as the cache, and a Premium Storage account is recommended because premium storage has higher throughput.

Important

If the storage key for your persistence account is regenerated, you must reconfigure the desired key from the Storage Key drop-down.

Click OK to save the persistence configuration.

The next backup (or first backup for new caches) is initiated once the backup frequency interval elapses.

Configure AOF persistence

To enable AOF persistence, click AOF. To disable AOF persistence on a previously enabled premium cache, click Disabled.

Redis AOF persistence

To configure AOF persistence, specify a First Storage Account. This storage account must be in the same region as the cache, and a Premium Storage account is recommended because premium storage has higher throughput. You can optionally configure an additional storage account named Second Storage Account. If a second storage account is configured, the writes to the replica cache are written to this second storage account. For each configured storage account, choose either the Primary key or Secondary key to use from the Storage Key drop-down.

Important

If the storage key for your persistence account is regenerated, you must reconfigure the desired key from the Storage Key drop-down.

When AOF persistence is enabled, write operations to the cache are saved to the designated storage account (or accounts if you have configured a second storage account). In the event of a catastrophic failure that takes down both the primary and replica cache, the stored AOF log is used to rebuild the cache.

Persistence FAQ

The following list contains answers to commonly asked questions about Azure Redis Cache persistence.

RDB persistence

AOF persistence

Can I enable persistence on a previously created cache?

Yes, Redis persistence can be configured both at cache creation and on existing premium caches.

Can I enable AOF and RDB persistence at the same time?

No, you can enable only RDB or AOF, but not both at the same time.

Which persistence model should I choose?

AOF persistence saves every write to a log, which has some impact on throughput, compared with RDB persistence which saves backups based on the configured backup interval, with minimal impact on performance. Choose AOF persistence if your primary goal is to minimize data loss, and you can handle a decrease in throughput for your cache. Choose RDB persistence if you wish to maintain optimal throughput on your cache, but still want a mechanism for data recovery.

For more information on performance when using AOF persistence, see Does AOF persistence affect throughout, latency, or performance of my cache?

What happens if I have scaled to a different size and a backup is restored that was made before the scaling operation?

For both RDB and AOF persistence:

  • If you have scaled to a larger size, there is no impact.
  • If you have scaled to a smaller size, and you have a custom databases setting that is greater than the databases limit for your new size, data in those databases isn't restored. For more information, see Is my custom databases setting affected during scaling?
  • If you have scaled to a smaller size, and there isn't enough room in the smaller size to hold all of the data from the last backup, keys will be evicted during the restore process, typically using the allkeys-lru eviction policy.

Can I change the RDB backup frequency after I create the cache?

Yes, you can change the backup frequency for RDB persistence on the Redis data persistence blade. For instructions, see Configure Redis persistence.

Why if I have an RDB backup frequency of 60 minutes there is more than 60 minutes between backups?

The RDB persistence backup frequency interval does not start until the previous backup process has completed successfully. If the backup frequency is 60 minutes and it takes a backup process 15 minutes to successfully complete, the next backup won't start until 75 minutes after the start time of the previous backup.

What happens to the old RDB backups when a new backup is made?

All RDB persistence backups except for the most recent one are automatically deleted. This deletion may not happen immediately but older backups are not persisted indefinitely.

When should I use a second storage account?

You should use a second storage account for AOF persistence when you believe you have higher than expected set operations on the cache. Setting up the secondary storage account helps ensure your cache doesn't reach storage bandwidth limits.

Does AOF persistence affect throughout, latency, or performance of my cache?

AOF persistence affects throughput by about 15% – 20% when the cache is below maximum load (CPU and Server Load both under 90%). There should not be latency issues when the cache is within these limits. However, the cache will reach these limits sooner with AOF enabled.

How can I remove the second storage account?

You can remove the AOF persistence secondary storage account by setting the second storage account to be the same as the first storage account. For instructions, see Configure AOF persistence.

What is a rewrite and how does it affect my cache?

When the AOF file becomes large enough, a rewrite is automatically queued on the cache. The rewrite resizes the AOF file with the minimal set of operations needed to create the current data set. During rewrites, expect to reach performance limits sooner especially when dealing with large datasets. Rewrites occur less often as the AOF file becomes larger, but will take a significant amount of time when it happens.

What should I expect when scaling a cache with AOF enabled?

If the AOF file at the time of scaling is significantly large, then expect the scale operation to take longer than expected since it will be reloading the file after scaling has finished.

For more information on scaling, see What happens if I have scaled to a different size and a backup is restored that was made before the scaling operation?

How is my AOF data organized in storage?

Data stored in AOF files is divided into multiple page blobs per node to increase performance of saving the data to storage. The following table displays how many page blobs are used for each pricing tier:

Premium tier Blobs
P1 4 per shard
P2 8 per shard
P3 16 per shard
P4 20 per shard

When clustering is enabled, each shard in the cache has its own set of page blobs, as indicated in the previous table. For example, a P2 cache with three shards distributes its AOF file across 24 page blobs (8 blobs per shard, with 3 shards).

After a rewrite, two sets of AOF files exist in storage. Rewrites occur in the background and append to the first set of files, while set operations that are sent to the cache during the rewrite append to the second set. A backup is temporarily stored during rewrites in case of failure, but is promptly deleted after a rewrite finishes.

Next steps

Learn how to use more premium cache features.