Update with new docs and configure UserAgent - #9
Merged
Conversation
lolodi
commented
May 7, 2026
lolodi
commented
Contributor
- Documentation got re-organized and expanded so updating the skill accordingly.
- Setting UserAgent in the calls our scripts make to identify skill usage.
- Enrich clustering guidance: add NoCluster for targets ≤24GB, OSS clustering for clustered sources - Fix non-TLS port from 'not supported' to '10000 (Plaintext mode)' - Update doc URLs from /azure/azure-cache-for-redis/ to /azure/redis/ - Surface 9 missing feature differences in main comparison docs - Add BSP tooling limitations (firewall rules, rollback window, hostname retention) - Bump Last Updated dates to May 2026 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
philon-msft
requested changes
May 7, 2026
| For detailed SKU mapping tables (Basic/Standard, Premium non-clustered, and Premium clustered with per-shard-count mappings), see the [SKU Mapping Guide](sku-mapping.md). | ||
|
|
||
| > **Important — Clustering Policy**: Non-clustered ACR caches (Basic, Standard, and non-clustered Premium) should be migrated to AMR with **Enterprise clustering policy** enabled. AMR uses clustering internally for all SKUs, and the default OSS clustering policy exposes cluster topology to the client, which may require application code changes (e.g., switching to a cluster-aware Redis client). Enterprise clustering policy hides this from the application, preserving the single-endpoint behavior these caches had on ACR. | ||
| > **Important — Clustering Policy**: Clustering policy selection is context-dependent. For non-clustered ACR caches (Basic, Standard, and non-clustered Premium) with target AMR SKU ≤ 24GB, use **NoCluster** to preserve the single-endpoint behavior these caches had on ACR, avoid cross-slot errors, and keep the option to upgrade to clustered later without recreating the database. For non-clustered source caches with target AMR SKU > 24GB, use **Enterprise clustering policy** because larger AMR caches require clustering, and Enterprise clustering hides cluster topology from the application so clients do not need to be cluster-aware. For clustered source caches (Premium with `shardCount` ≥ 1), use **OSS clustering** — the client is already cluster-aware, and OSS clustering offers better performance. |
Contributor
There was a problem hiding this comment.
should note that it's still possible to get CROSSSLOT errors with Enterprise clustering. I think we noted that somewhere, but I don't see it here. Should consolidate all clustering policy details in one spot?
Contributor
There was a problem hiding this comment.
I feel like we should expand this decision matrix for clustering policy to make it clearer. I'd suggest something like this:
If the ACR cache has clustering enabled, the AMR cache should always use the OSSCluster policy. No changes will be needed in the client application.
For other caches where the cache capacity will not exceed 24GB, a non-clustered AMR cache should be used.
Caches that do not meet the above criteria should use OSSCluster if possible. However, to use OSSCluster all of the following need to be true:
- The client is a .NET application using StackExchange.Redis OR the application can be updated to configure the client library to use clustered mode. See client library docs for guidance on how to connect to clustered Redis.
- The client does not use any multi-key commands or LUA scripts. If it does operate on multiple keys at once, the application may need to be updated to use hash tags to group related keys together into a single slot.
- The application is not planning to use the RediSearch module in AMR, which requires EnterpriseCluster.
If OSSCluster cannot be used for one of the reasons above, then EnterpriseCluster should be used. This is helpful for situations where the client application cannot be updated to connect to clustered Redis, because EnterpriseCluster emulates non-clustered Redis on a superficial level. However, EnterpriseCluster will have lower performance than OSSCluster and will still produce CROSSSLOT errors if a command or LUA script is executed that operates on keys spread across multiple slots.
| ### Step 3: Plan Migration | ||
| 1. Determine migration strategy (dual-write, snapshot/restore, etc.) | ||
| 2. **Clustering policy**: For non-clustered ACR caches (Basic, Standard, non-clustered Premium), create the AMR cache with **Enterprise clustering policy** to avoid client application changes. OSS clustering policy exposes cluster topology and may require a cluster-aware client. | ||
| 2. **Clustering policy**: Use a context-dependent policy based on the source cache and target AMR size. For non-clustered ACR caches (Basic, Standard, non-clustered Premium) with target AMR SKU ≤ 24GB, use **NoCluster** to preserve single-endpoint behavior, avoid cross-slot errors, and retain the option to upgrade to clustered later without recreating the database. For non-clustered source caches with target AMR SKU > 24GB, use **Enterprise clustering policy** because larger AMR caches require clustering, and Enterprise clustering hides cluster topology from clients that are not cluster-aware. For clustered source caches (Premium with `shardCount` ≥ 1), use **OSS clustering** — the client is already cluster-aware, and OSS clustering offers better performance. |
Contributor
There was a problem hiding this comment.
This looks like some dupe clustering policy info - we should consolidate into one spot
Contributor
Author
There was a problem hiding this comment.
good point, added a reference to the migaration-overview to avoid duplication
Suggestions from PR Co-authored-by: Philo <philon@microsoft.com>
- SKILL.md: replace dense clustering paragraph with pointer to reference docs - migration-overview.md: add CROSSSLOT warning for Enterprise clustering, link to canonical decision matrix in iac-amr-template-structure.md §6 Addresses PR AzureManagedRedis#9 review feedback from philon-msft. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace single-paragraph clustering callout with clearer decision flow: - ACR clustered -> OSSCluster (no client changes) - Non-clustered ≤ 24GB -> non-clustered AMR - Otherwise -> OSSCluster if criteria met, else EnterpriseCluster - Add CROSSSLOT warning for EnterpriseCluster - Add RediSearch/EnterpriseCluster requirement - Add hash tags guidance for multi-key commands Addresses PR AzureManagedRedis#9 review comment r3223118679 from philon-msft. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
philon-msft
approved these changes
May 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.