Redis Cloud clustering allows a database to scale horizontally by distributing data across multiple shards. This enables larger dataset sizes, higher throughput, and improved performance while applications continue to connect through a single endpoint. This guide explains when clustering is required, prerequisites for enabling it, how to configure clustering on existing or new databases, and how to troubleshoot common issues.
Prerequisites
Subscription: Clustering is available only on Redis Cloud Pro plans. Essentials plans do not support clustering.
Access: You must have account Owner or Admin permissions.
Workload review: Applications must use cluster-safe commands. Multi-key operations only work if all keys hash to the same slot. Review the Clustering Redis Databases.
How to Enable Clustering
Option 1: Enable on an Existing Database
Log into the Redis Cloud Console → Databases → select your database → Edit.
-
Increase the memory limit above 25GB (or 50GB if Auto-Tiering is enabled).
This automatically enables clustering.
Option 2: Create a New Clustered Database
From the Redis Cloud Console, select Create Database.
Choose a Pro subscription.
Set the size above 25GB or enable clustering in advanced options.
Specify shard count, throughput, and memory per shard.
Complete the database creation flow.
⚠️ Clustering Cannot Be Reverted
Once enabled, clustering is permanent for that database.
To return to a single-shard configuration, you must create a new database <25GB and migrate your data.
Plan accordingly before enabling clustering.
Best Practices and Limitations
Multi-key commands: Use hashtags ({tag}) to keep related keys in the same hash slot. See Multi-key Operations.
-
Hashing policies:
Accounts created after March 31, 2025 default to the Redis hashing policy.
⚠️ Changing hashing policy (Standard ↔ Custom) or disabling clustering triggers a FLUSHDB, deleting all data permanently.
-
OSS Cluster API:
Can be enabled in Pro plans for cluster-aware clients (see Redis OSS Cluster API).
⚠️ Enabling OSS Cluster API disables Search/Query and TimeSeries modules.
Before You Change Hashing Policy
Review your backup and export strategy.
Test in a non-production environment.
Plan downtime or migration windows since all data will be deleted during the change.
Rebuild data from source of truth after the change.
Troubleshooting Clustering Issues
Quick Fix Table
| Problem | Likely Cause | Solution |
|---|---|---|
| Cannot enable clustering | Database on Essentials plan | Upgrade to Pro subscription |
| CROSSSLOT error on multi-key commands | Keys mapped to different slots | Use hashtags to group related keys |
| CLUSTER command not allowed | OSS Cluster API not enabled | Enable OSS Cluster API (Pro only) |
| Search/Query not working in clustered DB | OSS Cluster API blocks modules | Disable OSS Cluster API or use non-clustered DB |
| Performance drop post-clustering | Shard imbalance / hot keys | Monitor shard distribution in Metrics and adjust key design or shard count |
| Cannot revert to single-shard DB | By design | Create a new DB <25GB and migrate data |
Monitoring Cluster Health
Use the Redis Cloud Console Metrics tab to view shard-level memory, CPU, and throughput.
Integrate with external observability tools such as Prometheus/Grafana or Datadog (Monitor Performance).
Configure alerts for throughput, latency, and replica sync errors.
Watch for uneven shard usage, which may indicate hot keys or poor hash-slot distribution.
0 comments
Please sign in to leave a comment.