Parameter Configuration
When creating a Redis instance, the system's default parameter template is applied.
Alauda Application Services provides specialized parameter templates for each Redis version (three templates for version 6.0+ and two for version 5.0) to accommodate different operational requirements.
| Parameter Template | Description | Considerations |
|---|---|---|
| RDB Parameter Template | RDB Persistence Parameter Template configures Redis with RDB persistence, which serializes the in-memory dataset to disk as binary snapshots at configured intervals. This approach is ideal for environments with limited resources that require a balance between performance and data durability, where minute-level data loss is acceptable. Redis can function as a persistent data store in this mode. | Data durability depends on the save parameter configuration, which typically provides minute-level recovery point objectives (RPOs). |
| AOF Parameter Template | AOF Persistence Parameter Template configures Redis with Append-Only File persistence, which logs all write operations sequentially to ensure data integrity. During instance recovery, Redis replays operations from the AOF file to reconstruct the dataset. This approach is suitable for environments with sufficient resources where data safety takes precedence over performance considerations. Redis can function as a persistent data store in this mode. | The frequent fsync operations required for AOF persistence necessitate high-performance storage infrastructure and may impact overall Redis performance, but provide second-level RPOs. |
| Diskless Parameter Template | Diskless Parameter Template disables Redis persistence mechanisms entirely. In this configuration, Redis functions purely as an in-memory cache to accelerate application performance. All data resides in memory with no disk persistence, resulting in data loss upon Redis restart or failure. This configuration maximizes performance but sacrifices data durability. | Data exists solely in memory, eliminating storage-related performance overhead. However, the failure of all Redis nodes results in complete data loss. |
When creating a Redis instance, select the template that best aligns with your business requirements in the Parameter Templates field of the Create Redis Instance page.
You can also create custom parameter templates for reuse across multiple instances.
Redis parameters fall into three categories based on how changes take effect:
| Category | Parameters | Behavior |
|---|---|---|
| Hot Update Parameters | Various parameters that support dynamic reconfiguration | Changes take effect immediately without requiring an instance restart. |
| Restart Update Parameters | databases, rename-command, rdbchecksum, tcp-backlog, io-threads, io-threads-do-reads | Changes require a full instance restart to take effect. |
| Non-Modifiable Parameters | bind, protected-mode, port, supervised, pidfile, dir, etc. | These parameters are either built-in system configurations or their modification after instance initialization could cause operational instability. |
When modifying Redis parameters, consider the following best practices:
- Before implementing parameter changes, determine whether the parameters support hot updates. For parameters requiring instance restart, perform appropriate data backups prior to modification.
- After upgrading Redis versions, review parameter compatibility in the Redis configuration documentation to identify deprecated, removed, or modified parameters.
TOC
Procedure
Data Node Parameters
The data node parameter configuration for the instance is specified through the spec.customConfig field of the Redis CR resource. Refer to the API documentation for detailed descriptions of the parameters.
Sentinel Node Parameters
The parameter configuration for data nodes registering to sentinel nodes is as follows:
Currently only supports the following three parameters:
down-after-milliseconds,failover-timeout,parallel-syncs.