Redis Sentinel Mode - Sadece Master Düğümün Replica'ları Var

Giriş

Sentinel ve Clustter mod farklı şeyler. Açıklaması şöyle. 

The sentinels are different concept than Redis cluster. If the primary dies then sentinels talk to each other to decide new primary.

Sentinel Nedir?

Açıklaması şöyle

It’s a solution that makes it easier to manage Redis instances. Since Redis 2.8, a stable release of Redis Sentinel has been available. Sentinel is a separate application that runs in the background. It will monitor your master and slave instances, alert you to any changes, manage automated failover in the event of a master failure, and perform as a configuration provider.

Şeklen şöyle

Sentinel'ler bir araya gelerek yeni Replica Set için Master'ı seçer. Açıklaması şöyle. 

Redis nodes can be interconnected by means of asynchronous replication. We’ll call such nodes a replica set. It is Redis Sentinel that manages the replica set. Redis Sentinel is one special process or several of them clustered, to monitor Redis nodes. They perform 4 primary tasks:

- Checking node status within the group - dead or alive.

- Notifying the system administrator if something goes wrong within the group.

- Automatic switching of the master.

- Config provider for external clients for them to know where to connect.

Yani 3 tane önemli görev var. Bunlar

1. Monitoring

2. Automatic failover

3. Configuration provider

Redis Primary-Secondary (Replica) Network with Sentinel without Sharding

Açıklaması şöyle. Bu modda veri dağıtılmıyor. Sadece master düğümün replica'ları var.

In scenarios where you don’t need sharding and one node is enough for your in-memory needs, you can avoid creating clusters and build primary-secondary replicas by specifying the replicaof in the replica configurations for the Redis node.

If we’re not using Redis clusters then we need sentinels to achieve failovers.

Master ve Replica şeklen şöyle

İyi ve kötü yanları şöyle

Redis Sentinel Pros:
- With three nodes, you can build up a fully functional Sentinel deployment. (Image 2)
- Simplicity - it’s usually simple to maintain and configure.
- Highly available, you can build a Redis Sentinel deployment that can survive certain failures without any need for human intervention.
- Work as long as a single master instance is available; it can survive the failure of all slave instances.
- Multiple slave nodes can replicate data from a master node.

Redis Sentinel Cons:
- Not scalable; writes must go to the master, cannot solve the problem of read-write separation.
- Slaves may serve reads, but because of asynchronous replication, outdated reads may result.
- It doesn’t shard data, so master and slave utilization will be imbalanced.
- The slave node is a waste of resources because it does not serve as a backup node.
- Redis-Sentinel must be supported by the client. The client holds half of the magic.

Sentinel Sayısı ve Quorum

Açıklaması şöyle. En az 3 sentinel kullanılır. Quorum sayısı sentinel sayısından az olabilir.

Sentinel documentation states that at least three sentinel instances are required for robust deployment. Although they can run as parallel processes in the same Redis instance, they should be placed into servers or VMs that are believed to fail independently.

Sentinel constantly checks the master for a failure. If enough sentinel agrees that the master is down then it acts as an authority and will start a failover process. As a result, it will promote a replica to be the master, configure other replicas to use new master until the master node is reachable again.

Sentinel agreement depends on the quorum value. Quorum value is the minimum number of the sentinels agree that the master is not reachable now. For 3 sentinel instances, the usual quorum value is 2.

Açıklaması şöyle

Quorum is configurable which only refers to the number of sentinels who must agree when a master is down. When in a failover scenario, sentinel instances attempt to reach a consensus, and at least three (odd number) sentinel instances will prevent most problems. These three Sentinel instances should also be placed on separate physical servers or Virtual Machines, as they are expected to fail in independent ways. 

Sentineller şeklen şöyle

Bağlantı

Açıklaması şöyle. Sentinel'ler kendi aralarında konuşmak için 26379 numaralı portu kullanır

The default port for Sentinel is 26379, so for sentinel instance to work, port 26379 of your servers must be open to receive connections from the IP addresses of the other sentinel instances. Otherwise, these instances can’t talk and agree about what to do, so failover will never be performed.

Bağlantı Timeout

Açıklaması şöyle.

You can configure the time required to check the master is down or not. Find down-after-milliseconds command which is the time in milliseconds to an instance should not be reachable for a Sentinel starting to think it is down. The default value is 30000 ms and you can change it as you like.

sentinel down-after-milliseconds mymaster 10000

Down Kavramı

Açıklaması şöyle.

Sentinel has two concepts of being down. Subjectively Down (SDOWN) condition is the local sentinel instance node thinks that Master is down. Objectively Down (ODOWN) condition is if enough instances (when quorum met) agree that the Master is not reachable.

Configure Sentinel to observe the Master with a specified quorum number.

# sentinel monitor <master-group-name> <ip> <port> <quorum>

sentinel monitor mymaster 127.0.0.1 6379 2

Çalıştırma

Şöyle yaparız

redis-sentinel /path/to/redis-sentinel*.conf