Alauda Cache Service for Redis OSS

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 TemplateDescriptionConsiderations
RDB Parameter TemplateRDB 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 TemplateAOF 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 TemplateDiskless 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:

CategoryParametersBehavior
Hot Update ParametersVarious parameters that support dynamic reconfigurationChanges take effect immediately without requiring an instance restart.
Restart Update Parametersdatabases, rename-command, rdbchecksum, tcp-backlog, io-threads, io-threads-do-readsChanges require a full instance restart to take effect.
Non-Modifiable Parametersbind, 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

CLI
Web Console

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.

# Update the data node configuration of instance s6
$ kubectl -n default patch redis s6 --type=merge --patch='{"spec": {"customConfig": {"save":"600 1"}}}'

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.

# Update the sentinel node configuration of instance s6
$ kubectl -n default patch redis s6 --type=merge --patch='{"spec": {"sentinel": {"monitorConfig": {"down-after-milliseconds":"30000","failover-timeout":"180000","parallel-syncs":"1"}}}}'