Understanding and Troubleshooting Flash Shards (Auto Tiering) in Redis Enterprise Software

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

Common Licensing Issues

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

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

1. Validate License

   • Confirm the license includes flash shard limits and is not expired.

   • Check via UI or GET /v1/license.

2. Verify Storage Configuration

   • Ensure SSD or NVMe flash devices are correctly mounted.

   • Run prepare_flash.sh on each node before enabling Auto Tiering.

3. Monitor Resource Utilization

   • As an operational guideline, keep flash disk usage below ~90% and CPU/RAM below ~80% sustained.

   • Use rladmin status and rlcheck to confirm overall cluster health before and after changes.

4. Inspect Flash Shard State

   • Run rladmin status shards (or use the Cluster Manager UI) and look for shards with state values such as error, unassigned, or out_of_sync on Auto Tiering databases. Investigate node-level issues (flash mount, disk errors, license violations) for any such shards.

5. 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.

6. 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.gz files and relevant logs when you open the Redis Support case.

Reference Links

• Flex and Auto Tiering quick start

• Cluster License Keys

• License REST API Reference

• Troubleshooting Redis Software

• Redis Software Reference