Flash shards (Auto Tiering) in Redis Software allow databases to use both RAM and flash storage (such as SSDs or NVMe drives) for cost-efficient scaling of large datasets. Hot data is kept in memory, while less frequently accessed data is moved to flash storage—maintaining high performance while reducing RAM costs.
This article explains what flash shards are, how they’re licensed and monitored, and includes step-by-step troubleshooting for common issues.
Key sections: What Are Flash Shards? | Licensing and Limits | Monitoring Flash Shard Usage | Troubleshooting Flash Shard Issues
What Are Flash Shards?
Flash shards, or Auto Tiering shards, enable hybrid data storage using both RAM and flash within the same Redis Software database. This is particularly beneficial for applications managing large datasets or analytics workloads that would otherwise exceed RAM capacity.
Flash shards are automatically managed by Redis: frequently accessed data remains in memory, while colder data is moved to flash storage.
To use Auto Tiering on VM/bare-metal clusters, ensure that flash storage is configured and formatted using the prepare_flash.sh script on each node before enabling the feature in the database configuration.
(For Kubernetes-based deployments, use the redisOnFlashSpec / flashShardsLimit fields in the RedisEnterpriseCluster CRD instead of running prepare_flash.sh directly.)
Flex (flash shards) was introduced in Redis Software 7.2 as the evolution of Flex. For production deployments, use Redis database version 7.2 or later on clusters that support Flex.
Licensing and Limits
License Behavior
As of Redis Software 7.2, licenses define limits for RAM shards and flash shards separately.
Type-specific shard limits (
ram_shards_limit,flash_shards_limit) supplement the legacy shards_limit field; enforcement is now by shard type rather than only by total shards.In the Cluster Manager UI, the flash shard limit is displayed only when Auto Tiering is enabled and at least one Auto Tiering database exists.
Viewing and Updating License Information
| Method | Action | Details |
|---|---|---|
| UI | Cluster → Configuration → General → License |
Displays license status, expiration date, and shard limits. |
| REST API |
|
Returns values such as |
Update License |
|
Installs a new license key. If validation fails, the request returns an error and the existing license remains active. If no valid license is installed, the cluster behaves as if the license were deleted (subject to expired-license behavior). |
Common Licensing Issues
| Issue | Cause | Resolution |
|---|---|---|
| License cannot be applied | Start date in the future | Request a new license with a valid start date. |
| License rejected | Cluster FQDN mismatch | Regenerate the license for the correct cluster name. |
| Flash shard usage not visible | Auto Tiering disabled | Enable Auto Tiering in the database configuration. |
Shard-type limits missing (no ram_shards_limit / flash_shards_limit in GET /v1/license)
|
Legacy license that defines only a total shards_limit
|
Enforcement is based on shards_limit only. Contact Redis Support if you need per-type RAM and flash shard limits for Auto Tiering deployments. |
Monitoring Flash Shard Usage
Flash shard usage and health can be monitored through the Cluster Manager UI, REST API, or Prometheus metrics.
UI Monitoring
The Cluster Manager displays flash shard usage and limits only when Auto Tiering is enabled on the cluster (and at least one Auto Tiering database exists).
API and Metrics
GET /v1/license — Reports shard usage and license limits.
-
Prometheus metrics include:
cluster_shards_limit{shard_type="flash"}— Flash shard limit per cluster.bdb_shards_used{shard_type="flash"}— Flash shards used per database.
Best Practice
Build a Grafana dashboard and alerts around cluster_shards_limit{shard_type="flash"} and bdb_shards_used{shard_type="flash"}, and trigger warnings as usage approaches 70–80% of licensed capacity or node flash capacity.
Troubleshooting Flash Shard Issues
Quick Fix Table
| Symptom | Likely Cause | Quick Fix |
|---|---|---|
| Cannot create new flash shard | License limit reached or expired | Check license status and limits; renew or upgrade the license. |
| License update fails | Invalid key, cluster name mismatch, or future start date | Verify the cluster FQDN, license key validity, and license start date. |
| Flash shard usage missing from UI | Auto Tiering not enabled | Enable Auto Tiering at the database level. |
| Flash shard performance degradation | Insufficient RAM or slow SSDs | Increase RAM, upgrade SSDs, or rebalance data tiering. |
| Shard allocation errors | Flash storage not mounted or formatted | Run prepare_flash.sh and verify flash mounts on all nodes. |
Flash storage must be prepared on every node before enabling Auto Tiering. Enabling Auto Tiering without prepared flash devices will cause shard allocation failures.
Step-by-Step Troubleshooting
-
Validate License
Confirm the license includes flash shard limits and is not expired.
Check via UI or
GET /v1/license.
-
Verify Storage Configuration
Ensure SSD or NVMe flash devices are correctly mounted.
Run
prepare_flash.shon each node before enabling Auto Tiering.
-
Monitor Resource Utilization
As an operational guideline, keep flash disk usage below ~90% and CPU/RAM below ~80% sustained.
Use
rladmin statusandrlcheckto confirm overall cluster health before and after changes.
-
Inspect Flash Shard State
Run
rladmin status shards(or use the Cluster Manager UI) and look for shards with state values such aserror,unassigned, orout_of_syncon Auto Tiering databases. Investigate node-level issues (flash mount, disk errors, license violations) for any such shards.
-
Review Logs and Alerts
Logs:
/var/opt/redislabs/log/Check for errors mentioning flash, tiering, or license.
Configure alerts for flash latency, disk I/O, and shard utilization.
-
Escalate with Support
-
If the issue persists, collect diagnostics and open a Redis Support case:
-
From any node, generate a cluster-level support package:
/opt/redislabs/bin/rladmin cluster debug_info
-
If that fails, generate node-level packages on each node:
/opt/redislabs/bin/debuginfo
Attach all resulting
.tar.gzfiles and relevant logs when you open the Redis Support case.
-
-
0 comments
Please sign in to leave a comment.