| title | description | author | ms.service | ms.topic | ms.date | ms.author | ms.custom |
|---|---|---|---|---|---|---|---|
How to administer Azure Cache for Redis |
Learn how to perform administration tasks such as reboot and schedule updates for Azure Cache for Redis |
flang-msft |
cache |
conceptual |
05/21/2021 |
franlanglois |
devx-track-azurepowershell |
This article describes how to do administration tasks such as rebooting and scheduling updates for your Azure Cache for Redis instances.
[!INCLUDE updated-for-az]
On the left, Reboot allows you to reboot one or more nodes of your cache. This reboot capability enables you to test your application for resiliency if there's a failure of a cache node.
Important
Reboot is not yet available for the Enterprise tier. Reboot is available for all other tiers.
:::image type="content" source="media/cache-administration/cache-administration-reboot-2.png" alt-text="Screenshot that highlights the Reboot menu option":::
Select the nodes to reboot and select Reboot.
:::image type="content" source="media/cache-administration/redis-cache-reboot-2.png" alt-text="Screenshot that shows which nodes you can reboot":::
If you have a premium cache with clustering enabled, you can select which shards of the cache to reboot.
:::image type="content" source="media/cache-administration/redis-cache-reboot-cluster-2.png" alt-text="screenshot of shard options":::
To reboot one or more nodes of your cache, select the nodes and select Reboot. If you have a premium cache with clustering enabled, select the shards to reboot and then select Reboot. After a few minutes, the selected nodes reboot, and are back online a few minutes later.
The effect on your client applications varies depending on which nodes you reboot.
- Master - When the primary node is rebooted, Azure Cache for Redis fails over to the replica node and promotes it to primary. During this failover, there may be a short interval in which connections may fail to the cache.
- Replica - When the replica node is rebooted, there's typically no effect on the cache clients.
- Both primary and replica - When both cache nodes are rebooted, you lose all data in the cache and connections to the cache fail until the primary node comes back online. If you have configured data persistence, the most recent backup is restored when the cache comes back online. However, any cache writes that occurred after the most recent backup are lost.
- Nodes of a premium cache with clustering enabled - When you reboot one or more nodes of a premium cache with clustering enabled, the behavior for the selected nodes is the same as when you reboot the corresponding node or nodes of a non-clustered cache.
- Which node should I reboot to test my application?
- Can I reboot the cache to clear client connections?
- Will I lose data from my cache if I do a reboot?
- Can I reboot my cache using PowerShell, CLI, or other management tools?
- Can I reboot my Enterprise cache?
To test the resiliency of your application against failure of the primary node of your cache, reboot the Master node. To test the resiliency of your application against failure of the replica node, reboot the Replica node. To test the resiliency of your application against total failure of the cache, reboot Both nodes.
Yes, if you reboot the cache, all client connections are cleared. Rebooting can be useful in the case where each client connection is used up because of a logic error or a bug in the client application. Each pricing tier has different client connection limits for the various sizes, and once these limits are reached, no more client connections are accepted. Rebooting the cache provides a way to clear all client connections.
Important
If you reboot your cache to clear client connections, StackExchange.Redis automatically reconnects once the Redis node is back online. If the underlying issue is not resolved, the client connections may continue to be used up.
If you reboot both the Master and Replica nodes, all data in the cache (or in that shard when you're using a premium cache with clustering enabled) might be lost. However, the data might not be lost either. If you have configured data persistence, the most recent backup is restored when the cache comes back online. However, any cache writes that have occurred after the backup was made are lost.
If you reboot just one of the nodes, data isn't typically lost, but it still might be. For example if the primary node is rebooted and a cache write is in progress, the data from the cache write is lost. Another scenario for data loss would be if you reboot one node and the other node happens to go down because of a failure at the same time. For more information about possible causes for data loss, see What happened to my data in Redis?
Yes, for PowerShell instructions see To reboot an Azure Cache for Redis.
No. Reboot isn't available for the Enterprise tier yet. Reboot is available for Basic, Standard and Premium tiers.The settings that you see on the Resource menu under Administration depend on the tier of your cache. You don't see Reboot when using a cache from the Enterprise tier.
On the left, Schedule updates allows you to choose a maintenance window for your cache instance. A maintenance window allows you to control the day(s) and time(s) of a week during which the VM(s) hosting your cache can be updated. Azure Cache for Redis will make a best effort to start and finish updating Redis server software within the specified time window you define.
Note
The maintenance window applies to Redis server updates and updates to the Operating System of the VMs hosting the cache. The maintenance window does not apply to Host OS updates to the Hosts hosting the cache VMs or other Azure Networking components. In rare cases, where caches are hosted on older models (you can tell if your cache is on an older model if the DNS name of the cache resolves to a suffix of "cloudapp.net", "chinacloudapp.cn", "usgovcloudapi.net" or "cloudapi.de"), the maintenance window won't apply to Guest OS updates either.
Currently, no option is available to configure a reboot or scheduled updates for an Enterprise tier cache.
:::image type="content" source="media/cache-administration/redis-schedule-updates-2.png" alt-text="Screenshot showing schedule updates":::
To specify a maintenance window, check the days you want and specify the maintenance window start hour for each day. Then, select OK. The maintenance window time is in UTC and can only be configured on an hourly basis.
The default, and minimum, maintenance window for updates is five hours. This value isn't configurable from the Azure portal, but you can configure it in PowerShell using the MaintenanceWindow parameter of the New-AzRedisCacheScheduleEntry cmdlet. For more information, see Can I manage scheduled updates using PowerShell, CLI, or other management tools?
- When do updates occur if I don't use the schedule updates feature?
- What type of updates are made during the scheduled maintenance window?
- Can I manage scheduled updates using PowerShell, CLI, or other management tools?
- Can an update that is covered and managed by the "Scheduled Updates" feature happen outside of the "Scheduled Updates" window?
If you don't specify a maintenance window, updates can be made at any time.
Only Redis server updates are made during the scheduled maintenance window. The maintenance window doesn't apply to Azure updates or updates to the VM operating system.
Yes, you can manage your scheduled updates using the following PowerShell cmdlets:
- Get-AzRedisCachePatchSchedule
- New-AzRedisCachePatchSchedule
- New-AzRedisCacheScheduleEntry
- Remove-AzRedisCachePatchSchedule
Can an update that is covered and managed by the Scheduled Updates feature happen outside the Scheduled Updates window?
Yes. In general, updates aren't applied outside the configured Scheduled Updates window. Rare critical security updates can be applied outside the patching schedule as part of our security policy.
Learn more about Azure Cache for Redis features.