Processo de implantação do Redis Sentinel

Versão

CentOS 8.1.1911（VMWare）
redis 5.0.8 

Informação básica

服务器IP：192.168.31.68
Redis 端口：7000（主） 7001，7002（从） Sentinel端口：27000 27001 27002 

• Os códigos ou comandos de chave são expressos assim

Configurar Redis

• master7000.conf

bind 0.0.0.0
port 7000
daemonize yes dir /home/misty/redis-data/sentinel01 pidfile /var/run/redis_7000.pid logfile "7000.log" dbfilename dump7000.rdb 

• slave7001.conf

bind 0.0.0.0
port 7001 daemonize yes dir /home/misty/redis-data/sentinel01 pidfile /var/run/redis_7001.pid logfile "7001.log" dbfilename dump7001.rdb slaveof 192.168.31.68 7000 

• slave7002.conf

bind 0.0.0.0
port 7002 daemonize yes dir /home/misty/redis-data/sentinel01 pidfile /var/run/redis_7002.pid logfile "7002.log" dbfilename dump7002.rdb slaveof 192.168.31.68 7000 

Inicie o serviço Redis

• Iniciar redis

redis-server master7000.conf
redis-server slave7001.conf redis-server slave7002.conf 

Serviço de verificação iniciado

$ ps -ef | grep redis-server | grep -v grep misty      4633   2639  0 03:16 ?        00:00:00 redis-server 0.0.0.0:7000 misty      4649   2639  0 03:16 ?        00:00:00 redis-server 0.0.0.0:7001 misty      4663   2639  0 03:16 ?        00:00:00 redis-server 0.0.0.0:7002 

Redis estabelece automaticamente um relacionamento mestre-escravo

redis:7000> info replication
# Replication
role:master connected_slaves:2 slave0:ip=192.168.31.68,port=7001,state=online,offset=630,lag=0 slave1:ip=192.168.31.68,port=7002,state=online,offset=630,lag=1 master_replid:187ff0474ccd0303571db1ca94174c46c2476dba master_replid2:0000000000000000000000000000000000000000 master_repl_offset:630 

Pode-se ver que o mestre aprendeu as informações dos dois nós escravos. Vale notar o deslocamento, os nós mestre e escravo determinam se eles foram sincronizados através do deslocamento.

redis:7001> info replication
# Replication
role:slave master_host:192.168.31.68 master_port:7000 master_link_status:up master_last_io_seconds_ago:6 master_sync_in_progress:0 slave_repl_offset:882 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:187ff0474ccd0303571db1ca94174c46c2476dba master_replid2:0000000000000000000000000000000000000000 master_repl_offset:882 

Preste atenção à slave_priority aqui.No modo sentinela, se o mestre cair, o sentinel primeiro decide quem será promovido a master com base na slave_priority.

Na configuração padrão, a slave_priority de todos os nós é a mesma, portanto, o maior será selecionado de acordo com o deslocamento.

Se você não conseguir selecionar um sucessor, escolha aquele com o menor ID de execução como mestre (o mais velho sênior).

O RunID é verificado através do servidor de informações.

No momento, pensamos que o nó principal está desligado e o nó escravo mostrará que o status do nó principal está inativo. O nó escravo não será atualizado automaticamente para o mestre.

# Replication
role:slave
master_host:192.168.31.68 master_port:7000 master_link_status:down master_last_io_seconds_ago:-1 

Após reiniciar o nó principal, o estado retorna para até

Configurar o Sentinel

• sentinel27000.conf

port 27000
daemonize yes
pidfile /var/run/redis-sentinel.pid logfile "sentinel27000.log" dir /home/misty/redis-data/sentinel01 sentinel monitor mymaster 192.168.31.68 7000 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 sentinel deny-scripts-reconfig yes 

Como o arquivo de configuração difere apenas no número da porta, apenas um arquivo de configuração é publicado. Pode ser criado em lotes através do comando sed

• sentinel27001.conf

sed "s/27000/27001/g" sentinel27000.conf > sentinel27001.conf

Notaremos que as informações de configuração do sentinel não identificam a existência de outros sentinelas, mas apenas as informações do nó mestre. Quando o serviço sentinela é iniciado, os nós sentinel detectam automaticamente a existência de outros nós sentinela e nós escravos através do nó mestre.

O Sentinel modificará o arquivo de configuração após a inicialização. É recomendável fazer backup do arquivo de configuração.

• Iniciar sentinela

redis-sentinel sentinel27000.conf
redis-sentinel sentinel27001.conf redis-sentinel sentinel27002.conf 

Verifique se o sentinela inicia com êxito:

> ps -ef | grep redis-sentinel | grep -v grep misty      5516   2639  0 03:59 ?        00:00:00 redis-sentinel *:27000 [sentinel] misty      5528   2639  0 04:00 ?        00:00:00 redis-sentinel *:27001 [sentinel] misty      5539   2639  0 04:00 ?        00:00:00 redis-sentinel *:27002 [sentinel] 

Use redis-cli para conectar-se a qualquer sentinela, execute informações sentinel, você obterá as mesmas informações

# Sentinel
sentinel_masters:1
sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=192.168.31.68:7000,slaves=2,sentinels=3 

Um grupo sentinela pode gerenciar vários grupos mestre-escravo redis, diferenciados por mestre: nome

Teste a comutação automática mestre-escravo

Encerramos 7000 nós, espere um momento, você descobrirá que o nó principal mudou para 7001 nós.

sentinel:27000> info sentinel
...
master0:name=mymaster,status=ok,address=192.168.31.68:7001,slaves=2,sentinels=3 

Isso mostra que ainda existem dois escravos: Ao olhar para o nó 7001, resta apenas um 7002 no escravo.

redis:7001> info replication
# Replication
...
slave0:ip=192.168.31.68,port=7002,state=online,offset=227471,lag=0 

Após reiniciar o serviço redis: 7000, ele é automaticamente definido como escravo de redis: 7001

redis:7001> info replication
# Replication
...
slave0:ip=192.168.31.68,port=7002,state=online,offset=299880,lag=0 slave1:ip=192.168.31.68,port=7000,state=online,offset=299880,lag=1 

Concluir

Nesse ponto, um grupo básico do Redis Sentinel é criado.

O nó redis sentinel é responsável apenas pelo monitoramento e não pelo encaminhamento de comandos como adicionar, excluir, modificar e verificar.O cliente ainda precisa se conectar ao nó mestre do Redis real para operação. (Diferente do cluster)

Apêndice: Java Connect Redis Sentinel

import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import redis.clients.jedis.JedisSentinelPool;

import java.util.HashSet;

public class Sentinel {
  public static void main(String[] args) { var poolConfig = new GenericObjectPoolConfig<>(); poolConfig.setMaxTotal(10); var sentinels = new HashSet<String>(); sentinels.add("192.168.31.68:27000"); sentinels.add("192.168.31.68:27001"); sentinels.add("192.168.31.68:27002"); var sentinelPool = new JedisSentinelPool("mymaster", sentinels, poolConfig, 30000); try (var jedis = sentinelPool.getResource()) { jedis.set("hello", "world"); System.out.println(jedis.get("hello")); } catch (Exception e) { e.printStackTrace(); } } } 

Se o Redis não conseguir se conectar, modifique o firewall do servidor e abra as portas relevantes

Princípio do cliente

• Selecione um nó Sentinel disponível
• Visite o sentinel para obter informações principais: sentinel get-master-addr-by-name mymaster
• Verifique o nó principal: role
• Criar um pool de conexão
• Monitore o sentinela e reconstrua o conjunto de conexões depois de descobrir que o nó principal foi alterado