Replication
Note: It is recommended to enable Sentinel mode for the Replication cluster for enhanced high availability and automatic failover. See Sentinel Mode section for configuration details.
Architecture
Redis is an in-memory key-value store that can be used as a database, cache, and message broker. Redis replication is the process of synchronizing data from a Redis leader node to one or more Redis follower nodes.
In Redis replication, the leader node is responsible for receiving write requests and propagating the changes to one or more follower nodes. The follower nodes receive the data changes from the leader and apply them locally, thereby creating a replica of the leader’s dataset.
Redis replication uses asynchronous replication, which means that the leader node does not wait for the follower nodes to apply the changes before sending new updates. Instead, the follower nodes catch up with the leader node as soon as they can, based on the available network bandwidth and the capacity of the hardware.
Redis replication is a powerful feature that enhances the durability and scalability of Redis applications. By using Redis replication, you can distribute the workload across multiple nodes, improve the read performance, and ensure data availability in case of a node failure.
Helm Installation
For redis replication setup we can use helm command with the reference of replication helm chart and additional properties:
$ helm install redis-replication ot-helm/redis-replication \
--set redisreplication.clusterSize=3 --namespace ot-operators
...
NAME: redis-replication
LAST DEPLOYED: Tue Mar 21 22:47:44 2023
NAMESPACE: ot-operators
STATUS: deployed
REVISION: 1
TEST SUITE: None
Verify the replication-cluster by checking the pod status of pods.
$ kubectl get pods -n ot-operators
...
NAME READY STATUS RESTARTS AGE
redis-replication-0 1/1 Running 0 2m23s
redis-replication-1 1/1 Running 0 99s
redis-replication-2 1/1 Running 0 59s
If all the pods are in the running, then we can check the health of the redis replication-cluster by using redis-cli. Here by default the 0th index redis pod is promoted to master.
YAML Installation
Examples folder has different types of manifests for different scenarios and features. There are these YAML examples present in this directory:
- additional_config
- advance_config
- affinity
- disruption_budget
- external_service
- password_protected
- private_registry
- probes
- redis_monitoring
- tls_enabled
- upgrade_strategy
A sample manifest for deploying redis replication-cluster:
---
apiVersion: redis.redis.opstreelabs.in/v1beta2
kind: RedisReplication
metadata:
name: redis-replication
spec:
clusterSize: 3
podSecurityContext:
runAsUser: 1000
fsGroup: 1000
kubernetesConfig:
image: quay.io/opstree/redis:v7.0.15
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 101m
memory: 128Mi
limits:
cpu: 101m
memory: 128Mi
storage:
volumeClaimTemplate:
spec:
# storageClassName: standard
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 1Gi
The yaml manifest can easily get applied by using kubectl.
kubectl apply -f replication.yaml
Sentinel Mode
RedisReplication supports an integrated Sentinel mode for automatic failover and high availability. When Sentinel mode is enabled, the operator deploys Redis Sentinel alongside the Redis replication cluster.
Enabling Sentinel Mode
Add the sentinel section to your RedisReplication spec:
---
apiVersion: redis.redis.opstreelabs.in/v1beta2
kind: RedisReplication
metadata:
name: redis-replication
spec:
clusterSize: 3
sentinel:
size: 3
image: quay.io/opstree/redis-sentinel:v7.0.15
imagePullPolicy: IfNotPresent
kubernetesConfig:
image: quay.io/opstree/redis:v7.0.15
imagePullPolicy: IfNotPresent
storage:
volumeClaimTemplate:
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 1Gi
Sentinel Configuration Options
| Field | Default | Description |
|---|---|---|
size |
- | Number of Sentinel instances (recommended: 3) |
quorum |
“2” | Number of Sentinels required to agree on master failure |
parallelSyncs |
“1” | Number of replicas that can sync with master in parallel during failover |
failoverTimeout |
“10000” | Failover timeout in milliseconds |
downAfterMilliseconds |
“5000” | Time in ms before a master is considered down |