Problem Index
Does Distributed Cache Database Support Data Persistence?
Both the Redis and Valkey engines support data persistence. By default, the system enables a hybrid persistence policy that combines RDB + AOF:
RDB (Redis Database Backup): periodically generates snapshots of memory data and writes them to disk, occupying less space and providing fast restoration.
AOF (Append Only File): records every write command, providing higher data security. By default, the system flushes data to disk once per second (appendfsync everysec), striking a balance between performance and data security.
Additionally, Distributed Cache provides both automatic and manual backup capabilities. The system automatically performs a full backup once a day, and backup data is retained for 7 days by default (configurable from 1 to 30 days). Users can also manually trigger a backup in the console at any time for data protection before changes.
Note:
The Memcached engine is a pure in-memory cache and does not support data persistence.
Is It Normal for a Newly Purchased Instance to Already Have 2 MB of Storage Used?
This is normal. It is the space used by the system to maintain its data structure, and it does not affect business usage.
What Is the Maximum Number of Connections Supported by an Instance?
The maximum number of connections for an instance depends on the architecture type and instance specification:
|
Standard architecture | 10,000 - 40,000 (increases with the specification) |
Cluster Architecture | 10,000 × Number of shards |
When the number of connections approaches the upper limit, you can optimize it in the following ways:
Check whether the client uses a connection pool to avoid frequent creation and termination of connections.
Check whether there are connection leaks (connections that remain idle for a long time without being released).
If your business truly requires more connections, you can raise the connection limit by upgrading the instance specification or increasing the number of shards.
How to Resolve High Memory Usage of an Instance?
When instance memory utilization consistently exceeds 80%, take the following measures:
Troubleshoot Big Keys
Log in to the console and use the big Key analysis feature to scan for big keys in the instance. Big keys not only consume a large amount of memory, but may also cause increased request latency and master-replica sync interruptions. We recommend that you split keys larger than 10 MB into multiple smaller keys, or use a Hash structure instead of a single large String.
Check the expiration policy
Confirm whether business data has a reasonable time-to-live (TTL) set. If many keys do not have a TTL set, memory usage will continue to grow. You can use the OBJECT IDLETIME command to check the idle time of keys, and set an expiration policy or manually clean up data that has not been accessed for a long time.
Scale out the instance
If memory utilization remains high after optimization, the current specification can no longer meet your business needs. You can perform an online capacity expansion in the console. The standard architecture supports vertical scaling (increasing memory specifications), while the cluster architecture supports horizontal scaling (increasing the number of shards). The expansion process typically completes within minutes, during which the instance remains available for normal reads and writes.
Do Scale-Out and Scale-In Interrupt Services?
The impact of scaling on your business depends on the operation type:
|
Vertical scaling (memory expansion) | A momentary disconnection at the second level may occur. | If the remaining capacity of a single node is exceeded, node migration is performed and a momentary disconnection at the second level occurs. If it is not exceeded, no impact occurs. |
Vertical scale-down (memory reduction) | No interruption | No momentary disconnection at the second level will occur. |
Horizontal scaling out (adding shards) | Momentary disconnection at the second level. | Adding a node will trigger data migration. |
Horizontal scaling in (removing shards) | Momentary disconnection at the second level. | Recycling a node will trigger data migration. |
We recommend that you perform scaling operations during off-peak hours or within the maintenance window to minimize the impact on your business.
Does the Instance Support Version Upgrade?
Yes. Distributed Cache supports two upgrade methods: major version upgrades and minor version upgrades.
Major version upgrade: It supports cross-version upgrades, such as upgrading from Redis 5.0 to Redis 6.2 or 7.0, after which you can use the features and commands of the new version. A brief connection interruption (usually a few seconds) occurs during the upgrade, so we recommend that you perform the upgrade within the maintenance window.
Minor version upgrade: The system periodically releases minor version updates that include performance optimizations and security fixes. You can trigger the update manually or set it to update automatically within the maintenance window.
Proxy version upgrade: The engine version and Proxy version can be upgraded independently without affecting each other.
Note:
Version upgrade is irreversible. Before upgrading, ensure that your business code is compatible with the target version. We recommend that you validate the upgrade in a test environment before performing it in the production environment.
Does the Instance Support Upgrade from Standard Architecture to Cluster Architecture?
Yes. You can upgrade the architecture on the instance details page in the console to upgrade a standard architecture instance to cluster architecture. A brief connection interruption occurs during the upgrade, so we recommend that you perform the upgrade within the maintenance window.
Why Is Available Memory Less Than the Purchased Specification?
This is because the system reserves some memory for master-replica synchronization and internal management operations to ensure stable instance running.
Purpose of Reserved Memory:
Master-replica replication buffer: The master node needs to use a buffer (replication backlog) when syncing data to replica nodes, which occupies a certain amount of memory by default.
System process overhead: The Redis process itself consumes a small amount of memory to run.
Copy-On-Write reservation: When an RDB backup or AOF rewrite is performed, the fork child process may cause memory usage to double (Copy-On-Write). Reserve space to prevent the system from killing the process due to OOM.
Output buffer: The output buffers for clients and master-replica synchronization require additional memory.
Actual Available Memory by Specification:
Actual available memory = purchased specification memory - system reserved memory. System reserved memory is typically 15% to 20% of the total specification. For example, if you purchase an instance with a 4 GB specification, the actual writable data capacity is approximately 3.2 GB to 3.4 GB.
Recommendations:
During capacity planning, estimate based on the actual available memory and reserve a 20% margin.
Set the memory utilization alarm threshold to 65% - 75% to trigger capacity expansion evaluation in advance.
If the memory limit is frequently approached, upgrade the specification instead of relying on eviction policies.