Merge pull request #252500 from shpathak-msft/flush-update-channels

Add docs update flush and update channel

Author: denrea

articles/azure-cache-for-redis/TOC.yml

@@ -204,8 +204,8 @@
       href: cache-how-to-encryption.md
     - name: Reboot
       href: cache-administration.md#reboot
-    - name: Schedule updates
-      href: cache-administration.md#schedule-updates
+    - name: Update channel and schedule updates
+      href: cache-administration.md#update-channel-and-schedule-updates
     - name: Configure redis-cli.exe access
       href: cache-how-to-redis-cli-tool.md
     - name: Create and manage a cache using CLI

articles/azure-cache-for-redis/cache-administration.md

@@ -5,12 +5,12 @@ author: flang-msft
 
 ms.service: cache
 ms.topic: conceptual
-ms.date: 07/22/2021
+ms.date: 09/29/2023
 ms.author: franlanglois 
 ---
 # How to administer Azure Cache for Redis
 
-This article describes how to do administration tasks such as [rebooting](#reboot) and [scheduling updates](#schedule-updates) for your Azure Cache for Redis instances.
+This article describes how to do administration tasks such as [rebooting](#reboot) and [Update channel and Schedule updates](#update-channel-and-schedule-updates) for your Azure Cache for Redis instances.
 
 [!INCLUDE [updated-for-az](../../includes/updated-for-az.md)]
 
@@ -38,7 +38,7 @@ The effect on your client applications varies depending on which nodes you reboo
 
 * **Primary** - 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, Azure Cache for Redis will attempt to gracefully reboot both nodes, waiting for one to finish before rebooting the other. Typically, data loss does not occur. However, data loss can still occur do to unexpected maintenance events or failures. Rebooting your cache many times in a row increases the odds of data loss.
+* **Both primary and replica** - When both cache nodes are rebooted, Azure Cache for Redis attempts to gracefully reboot both nodes, waiting for one to finish before rebooting the other. Typically, data loss doesn't occur. However, data loss can still occur do to unexpected maintenance events or failures. Rebooting your cache many times in a row increases the odds of data loss.
 * **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.
 
 ## Reboot FAQ
@@ -76,15 +76,33 @@ Yes, for PowerShell instructions see [To reboot an Azure Cache for Redis](cache-
 
 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.
 
-## Schedule updates
+## Flush data (preview)
 
-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.
+When using the Basic, Standard, or Premium tiers of Azure Cache for Redis, you see **Flush data** on the resource menu. The **Flush data** operation allows you to delete or _flush_ all data in your cache. This _flush_ operation can be used before scaling operations to potentially reduce the time required to complete the scaling operation on your cache. You can also configure to run the _flush_ operation periodically on your dev/test caches to keep memory usage in check.
 
-> [!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.
+The _flush_ operation, when executed on a clustered cache, clears data from all shards at the same time.
+
+> [!IMPORTANT]
+> Previously, the _flush_ operation was only available for geo-replicated Enterprise tier caches. Now, it is available in Basic, Standard and Premium tiers.
 >
-> Currently, no option is available to configure a reboot or scheduled updates for an Enterprise tier cache.
+:::image type="content" source="media/cache-administration/cache-flush.png" alt-text="Screenshot showing flush data selected in the resource menu of a cache instance. ":::
+
+## Update channel and Schedule updates
+
+On the left, **Schedule updates** allows you to choose an update channel and a maintenance window for your cache instance.
+
+Any cache instance using the **Stable** update channel receives updates a few weeks later than cache instances using **Preview** update channel. We recommend choosing the **Preview** update channel for your non-production and less critical workloads. Choose the **Stable** update channel for your most critical, production workloads. All caches default to the **Stable** update channel by default.
+
+> [!IMPORTANT]
+> Changing the update channel on your cache instance results in your cache undergoing a patching event to apply the right updates. Consider changing the update channel during your maintenance window.
+>
+
+A maintenance window allows you to control the days and times of a week during which the VMs hosting your cache can be updated. Azure Cache for Redis makes a best effort to start and finish updating Redis server software within the specified time window you define.
+
+> [!IMPORTANT]
+> The update channel and maintenance window applies to Redis server updates and updates to the Operating System of the VMs hosting the cache. The update channel and 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 the maintenance window won't apply to Guest OS updates either. 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`.
 >
+Currently, no option is available to configure an update channel 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":::
 

articles/azure-cache-for-redis/cache-best-practices-connection.md

@@ -6,7 +6,7 @@ author: flang-msft
 
 ms.service: cache
 ms.topic: conceptual
-ms.date: 02/27/2023
+ms.date: 09/29/2023
 ms.author: franlanglois
 ---
 
@@ -22,7 +22,7 @@ Test your system's resiliency to connection breaks using a [reboot](cache-admini
 
 ## TCP settings for Linux-hosted client applications
 
-The default TCP settings in some Linux versions can cause Redis server connections to fail for 13 minutes or more. The default settings can prevent the client application from detecting closed connections and restoring them automatically if the connection wasn't closed gracefully. 
+The default TCP settings in some Linux versions can cause Redis server connections to fail for 13 minutes or more. The default settings can prevent the client application from detecting closed connections and restoring them automatically if the connection wasn't closed gracefully.
 
 The failure to reestablish a connection can happen in situations where the network connection is disrupted or the Redis server goes offline for unplanned maintenance.
 
@@ -77,19 +77,19 @@ Use notifications to learn of upcoming maintenance. For more information, see [C
 
 ## Schedule maintenance window
 
-Adjust your cache settings to accommodate maintenance. For more information about creating a maintenance window to reduce any negative effects to your cache, see [Schedule updates](cache-administration.md#schedule-updates).
+Adjust your cache settings to accommodate maintenance. For more information about creating a maintenance window to reduce any negative effects to your cache, see [Update channel and Schedule updates](cache-administration.md#update-channel-and-schedule-updates).
 
 ## More design patterns for resilience
 
 Apply design patterns for resiliency. For more information, see [How do I make my application resilient](cache-failover.md#how-do-i-make-my-application-resilient).
 
 ## Idle timeout
 
-Azure Cache for Redis has a 10-minute timeout for idle connections. The 10-minute timeout allows the server to automatically clean up leaky connections or connections orphaned by a client application. Most Redis client libraries have a built-in capability to send `heartbeat` or `keepalive` commands periodically to prevent connections from being closed even if there are no requests from the client application. 
+Azure Cache for Redis has a 10-minute timeout for idle connections. The 10-minute timeout allows the server to automatically clean up leaky connections or connections orphaned by a client application. Most Redis client libraries have a built-in capability to send `heartbeat` or `keepalive` commands periodically to prevent connections from being closed even if there are no requests from the client application.
 
 If there's any risk of your connections being idle for 10 minutes, configure the `keepalive` interval to a value less than 10 minutes. If your application is using a client library that doesn't have native support for `keepalive` functionality, you can implement it in your application by periodically sending a `PING` command.
 
-## Next steps
+## Related content
 
 - [Best practices for development](cache-best-practices-development.md)
 - [Azure Cache for Redis development FAQ](cache-development-faq.yml)

articles/azure-cache-for-redis/cache-best-practices-scale.md

@@ -45,7 +45,7 @@ For more information on scaling and memory, depending on your tier see either:
 
 ## Minimizing your data helps scaling complete quicker
 
-If preserving the data in the cache isn't a requirement, consider flushing the data prior to scaling. Flushing the cache helps the scaling operation complete more quickly so the new capacity is available sooner.
+If preserving the data in the cache isn't a requirement, consider flushing the data prior to scaling. Flushing the cache helps the scaling operation complete more quickly so the new capacity is available sooner. See more details on [how to initiate flush operation.](cache-administration.md#flush-data-preview)
 
 ## Scaling Enterprise tier caches
 

articles/azure-cache-for-redis/cache-configure.md

@@ -5,7 +5,7 @@ author: flang-msft
 
 ms.service: cache
 ms.topic: conceptual
-ms.date: 11/21/2022
+ms.date: 09/29/2023
 ms.author: franlanglois 
 ms.custom: engagement-fy23
 ---
@@ -185,7 +185,7 @@ Use the **Maxmemory policy**, **maxmemory-reserved**, and **maxfragmentationmemo
 
 **Maxmemory policy** configures the eviction policy for the cache and allows you to choose from the following eviction policies:
 
-- `volatile-lru`: The default eviction policy, removes the least recently used key out of all the keys with an expiration set. 
+- `volatile-lru`: The default eviction policy. It removes the least recently used key out of all the keys with an expiration set.
 - `allkeys-lru`: Removes the least recently used key.
 - `volatile-random`: Removes a random key that has an expiration set.
 - `allkeys-random`: Removes a random key.
@@ -264,7 +264,7 @@ The **Schedule updates** section on the left allows you to choose a maintenance
 
 To specify a maintenance window, check the days you want. Then, specify the maintenance window start hour for each day, and select **OK**. The maintenance window time is in UTC.
 
-For more information and instructions, see [Azure Cache for Redis administration - Schedule updates](cache-administration.md#schedule-updates)
+For more information and instructions, see [Update channel and Schedule updates](cache-administration.md#update-channel-and-schedule-updates).
 
 ### Geo-replication
 
@@ -478,7 +478,7 @@ New Azure Cache for Redis instances are configured with the following default Re
 | `lua-event-limit` |500 |Max size of script event queue. |
 | `client-output-buffer-limit normal` / `client-output-buffer-limit pubsub` |`0 0 0` / `32mb 8mb 60` |The client output buffer limits can be used to force disconnection of clients that aren't reading data from the server fast enough for some reason. A common reason is that a Pub/Sub client can't consume messages as fast as the publisher can produce them. For more information, see [https://redis.io/topics/clients](https://redis.io/topics/clients). |
 
-<a name="databases"></a>
+### Databases
 
 <sup>1</sup>The limit for `databases` is different for each Azure Cache for Redis pricing tier and can be set at cache creation. If no `databases` setting is specified during cache creation, the default is 16.
 
@@ -504,9 +504,9 @@ For more information about databases, see [What are Redis databases?](cache-deve
 > The `databases` setting can be configured only during cache creation and only using PowerShell, CLI, or other management clients. For an example of configuring `databases` during cache creation using PowerShell, see [New-AzRedisCache](cache-how-to-manage-redis-cache-powershell.md#databases).
 >
 
-<a name="maxclients"></a>
+### Maxclients
 
-<sup>2</sup>`maxclients` is different for each Azure Cache for Redis pricing tier.
+<sup>2</sup>The `maxclients` property is different for each Azure Cache for Redis pricing tier.
 
 - Basic and Standard caches
   - C0 (250 MB) cache - up to 256 connections
@@ -556,8 +556,7 @@ For cache instances using active geo-replication, the following commands are als
 
 For more information about Redis commands, see [https://redis.io/commands](https://redis.io/commands).
 
-## Next steps
+## Related content
 
 - [How can I run Redis commands?](cache-development-faq.yml#how-can-i-run-redis-commands-)
 - [Monitor Azure Cache for Redis](cache-how-to-monitor.md)
-

articles/azure-cache-for-redis/cache-failover.md

@@ -6,7 +6,7 @@ author: flang-msft
 ms.author: franlanglois
 ms.service: cache
 ms.topic: conceptual
-ms.date: 11/16/2022
+ms.date: 09/29/2023
 ms.custom: engagement-fy23
 
 ---
@@ -114,12 +114,12 @@ Refer to these design patterns to build resilient clients, especially the circui
 
 To test a client application's resiliency, use a [reboot](cache-administration.md#reboot) as a manual trigger for connection breaks.
 
-Additionally, we recommend that you [schedule updates](cache-administration.md#schedule-updates) on a cache to apply Redis runtime patches during specific weekly windows. These windows are typically periods when client application traffic is low, to avoid potential incidents.
+Additionally, we recommend that you [Update channel and Schedule updates](cache-administration.md#update-channel-and-schedule-updates) on a cache to apply Redis runtime patches during specific weekly windows. These windows are typically periods when client application traffic is low, to avoid potential incidents.
 
 For more information, see [Connection resilience](cache-best-practices-connection.md).
 
-## Next steps
+## Related content
 
-- [Schedule updates](cache-administration.md#schedule-updates) for your cache.
-- Test application resiliency by using a [reboot](cache-administration.md#reboot).
-- [Configure](cache-configure.md#memory-policies) memory reservations and policies.
+- [Update channel and Schedule updates](cache-administration.md#update-channel-and-schedule-updates)
+- Test application resiliency by using a [reboot](cache-administration.md#reboot)
+- [Configure](cache-configure.md#memory-policies) memory reservations and policies