Redis Cluster is a distributed implementation of Redis with the following goals,
- High performance and linear scalability up to 1000 nodes. Starting with Redis 3.0, asynchronous replication is used, and no merge operations are performed on values.
- Acceptable degree of write safety: the system tries (in a best-effort way) to retain all the writes originating from clients connected with the majority of the master nodes. Usually there are small windows where acknowledged writes can be lost. Windows to lose acknowledged writes are larger when clients are in a minority partition.
- Availability: Redis Cluster is able to survive to partitions where the majority of the master nodes are reachable and there is at least a reachable slave for every master node that is no longer reachable. Moreover using replicas migration, masters no longer replicated by any slave, will receive one from a master which is covered by multiple slaves.
Redis clustering the data can be shared(divided) into many computers. The main advantage is that more data can be stored in a cluster because its a combination of computers.
All redis nodes interconnected using PING-PONG mechanism. And the cluster is responsible for maintenance of the cluster nodes.
- cluster-enabled <yes/no>
- ex: cluster-enabled yes
- Note: If yes to enable the Redis Cluster. Otherwise the instance starts as a stand alone instance as usually.
- cluster-config-file <filename>
- ex: cluster-config-file node-6379.conf
- Note: Cluster configuration file is not an user editable, but the file where a Redis Cluster node automatically persists the cluster configuration (the state, basically) every time there is a change, in order to be able to reread it at startup. The file lists things like the other nodes in the cluster, their state, persistent variables, and so forth. Often this file is rewritten and flushed on disk as a result of some message reception.
- cluster-node-timeout <milliseconds>
- ex: cluster-node-timeout 5000
- Note: The maximum amount of time a Redis Cluster node can be unavailable, without it being considered as failing. If a master node is not reachable for more than the specified amount of time, it will be failed over by its replica.
- cluster-slave-validity-factor <factor>
- ex: cluster-slave-validity-factor 0
- Note: If set to zero, a slave will always try to fail-over a master, regardless of the amount of time the link between the master and the slave remained disconnected. If the value is positive, a maximum disconnection time is calculated as the node timeout value multiplied by the factor provided with this option, and if the node is a slave, it will not try to start a fail-over if the master link was disconnected for more than the specified amount of time.
- cluster-migration-barrier <count>
- ex: cluster-migration-barrier 1
- Note: Minimum number of slaves a master will remain connected with, for another slave to migrate to a master which is no longer covered by any slave.