Resizing a CRDB (Active-Active) database in Redis Software changes the global configuration across all participating clusters. Resizing can mean increasing the memory limit for larger datasets or changing the number of shards to scale throughput. Unlike standalone databases, CRDB configuration changes should be applied using the crdb-cli tool or API. UI changes are local to one region and can cause inconsistent states. If the UI is utilized, the same adjustments should be completed within all participating clusters.
This guide covers what resizing means, step-by-step CLI operations, troubleshooting common errors, and best practices for availability and durability.
Prerequisites
Admin access to all Redis Software clusters in the CRDB.
Cluster health check: No stale replicas (STALE REPLICA) or unhealthy nodes.
Backups: Ensure recent backups are available before resizing.
Headroom: Confirm all nodes have enough provisional RAM for the new limits (rladmin status extra all).
-
Data checks:
Identify large or hot keys with redis-cli --bigkeys, redis-cli --hotkeys, or redis-cli --keystats (If on version 7.4 and on). Oversized keys can slow or stall resharding.
Avoid large DEL operations before resizing. Use UNLINK or scan-and-delete to free memory without blocking.
Before You Start Checklist
Confirm enough provisional memory across all cluster nodes (rladmin status).
Verify recent backups exist and are restoreable.
Identify and break up large or hot keys (redis-cli --bigkeys, --hotkeys, and --keystats).
Use UNLINK for safe bulk deletes (avoid DEL).
Ensure no stale replicas or unhealthy nodes.
Schedule the resize during a low-traffic window.
Step-by-Step Resizing
Step 1. Find the CRDB GUID
crdb-cli crdb listExample output:
CRDB-GUID NAME REPL-ID CLUSTER-FQDN
af01a030-6c45-47ec-b273-b116eab0eb03 my-crdb 1 site1...
af01a030-6c45-47ec-b273-b116eab0eb03 my-crdb 2 site2...Step 2. Check Current Config
crdb-cli crdb get --crdb-guid <CRDB-GUID>Key fields:
memory_size (bytes)
shards_count (number of primary shards)
Shard sizing note
CRDB does not define a universal fixed maximum size per shard. The practical shard capacity depends on the database memory limit, shard count, replica/HA configuration, Active-Active overhead, modules, and available cluster memory.
Avoid sizing shards based only on raw dataset size. The configured database memory limit must account for all shards and replicas, along with additional overhead such as Active-Active metadata, replication backlog, modules, and operational activities (for example, resharding).
Step 3. Apply Resize
Increase memory to 8 GB:
crdb-cli crdb update --crdb-guid <CRDB-GUID> --memory-size 8GBChange shard count to 4:
crdb-cli crdb update --crdb-guid <CRDB-GUID> --default-db-config '{"shards_count":4}'Do both at once (note: memory_size in bytes):
crdb-cli crdb update --crdb-guid <CRDB-GUID> \
--default-db-config '{"memory_size":8589934592,"shards_count":4}'Track task progress:
crdb-cli task status --task-id <Task-ID>
crdb-cli task listImportant: Resharding can only increase the shard count. Reducing shards within a CRDB requires downtime and Redis Support involvement.
Quick Reference: Common Commands
| Operation | Command |
|---|---|
| List CRDBs | crdb-cli crdb list |
| Show config | crdb-cli crdb get --crdb-guid <CRDB-GUID> |
| Resize memory | crdb-cli crdb update --crdb-guid <CRDB-GUID> --memory-size 8GB |
| Resize shards | crdb-cli crdb update --crdb-guid <CRDB-GUID> --default-db-config '{"shards_count":4}' |
| Check tasks |
crdb-cli task list / crdb-cli task status --task-id <Task-ID>
|
Troubleshooting Quick Fix Table
| Symptom | Likely Cause | Fix |
|---|---|---|
| “Not Enough Memory in the Cluster” | Nodes lack free provisional RAM for shards + replicas | Run rladmin status; redistribute shards, free up memory, or add memory |
| Changes not visible in UI | UI only reflects local config | Use crdb-cli as source of truth |
| “CRDB database is currently busy” | Another config/sync task running | Wait then retry or contact Support |
| Task in progress | Lock file or orphan task | Confirm sync, check task status/progress, or contact Support |
| Sync issues, stale replicas, or OOM after resize | Large keys, sync lag, or connectivity issues | Use redis-cli --bigkeys; break up large keys; use UNLINK for deletes; confirm resolution and network stability between participating clusters |
Best Practices
Always use crdb-cli for Active-Active changes.
Schedule resizes during low-traffic windows.
Monitor task completion across all sites before assuming success.
For high throughput (>100K ops/sec), configure at least 8 master shards.
Resharding is most efficient when doubling shards (x2). Any increase is allowed, but shard reduction requires downtime.
Avoid bulk DEL during maintenance — prefer UNLINK or incremental deletes.
Ensure nodes have enough RAM for both data and replication.
Collect a support package if problems persist.
0 comments
Please sign in to leave a comment.