Resize a CRDB Database

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 list

Example 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 8GB

• Change 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 list

Important: Resharding can only increase the shard count. Reducing shards within a CRDB requires downtime and Redis Support involvement.

Quick Reference: Common Commands

Troubleshooting Quick Fix Table

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.