Simplificando, uma sentinela é um denunciante que inspeciona e monitora se o host mestre em segundo plano está com defeito. Se falhar, ele converterá automaticamente um determinado banco de dados escravo em um novo banco de dados mestre de acordo com o número de votos e continuará para servir o mundo exterior.

efeito

Sentinel tem as seguintes quatro funções principais:

Monitoramento mestre-escravo

Monitore se a biblioteca redis master-slave está rodando normalmente

notificação

Sentinela pode enviar resultados de failover para clientes

failover

Se o mestre estiver anormal, uma troca mestre-escravo será realizada e um dos escravos será usado como o novo mestre

centro de configuração

O cliente obtém o endereço do nó mestre do serviço Redis atual conectando-se ao sentinela

Resumindo em uma frase, as principais funções do Sentinels são as seguintes:

1. Monitore o status de execução do redis, incluindo mestre e escravo

2. Quando o mestre está inativo, ele pode alternar automaticamente o escravo para o novo mestre

Como usar o Sentinel (demonstração de caso + passos práticos)

Arquitetura sentinela do Redis explicada com antecedência

Nossa configuração para verificar o papel do redis sentry é a seguinte:

3 sentinelas

Monitore e mantenha clusters automaticamente, não armazene dados, apenas monitore

1 mestre 2 escravos

Para leitura e armazenamento de dados

Crie ou copie sentinel.conf no diretório /myredis

Primeiro, observe o conteúdo do arquivo sentinela.conf padrão no diretório de descompactação redis

Configuração do parâmetro chave

Parâmetros de arquivo do Sentinel (líder)
endereço de escuta do serviço de ligação, usado para conexão do cliente (endereço local por padrão)
daemonize se deve ser executado como daemon de segundo plano
modo protegido segurança modo de proteção
porta porta
arquivo de log caminho do arquivo
de log pidfile pid caminho do log
dir diretório de trabalho

sentinela monitor <master> <redis-port> <quorum>

Definir o quorm mestre a ser monitorado significa que pelo menos algumas sentinelas concordam em ficar off-line objetivamente e concordam com o número estatutário de votos para migração de falhas

Sabemos que a rede não é confiável. Às vezes, um sentinela pensará erroneamente que um redis mestre morreu devido ao congestionamento da rede. Em um ambiente de cluster sentinela, vários sentinelas precisam se comunicar entre si para confirmar se um mestre está realmente morto . O parâmetro o quorum é uma base para o objetivo off-line, o que significa que pelo menos os sentinelas do quorum acreditam que o mestre está com defeito e, então, o mestre ficará off-line e fará failover. Porque, às vezes, um nó sentinela pode não conseguir se conectar ao mestre devido a seus próprios motivos de rede, e o mestre não está com defeito neste momento, portanto, vários sentinelas precisam concordar que o mestre tem um problema antes de prosseguir para o próximo operação passo a passo, o que garante imparcialidade e alta disponibilidade.

sentinela auth-pass <master-name> <password> // Conecta ao master através de senha

//Conecte-se ao host através de uma senha. Deve-se observar aqui que mesmo que seja um arquivo de configuração no host, ainda precisamos configurar isso, porque depois que nosso host desliga e reinicia, ele não é mais o host por padrão, e ele é reconhecido como escravo. , neste momento ele também precisa se conectar ao novo host

Configuração de arquivo comum para este caso

Configuramos os seguintes arquivos de configuração do sentinela

sentinela26381.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

sentinela26380.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

sentinela26379.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

Sobre outras configurações no arquivo sentinela

sentinel down-after-milliseconds <master-name> <milliseconds>：

指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

 

sentinel parallel-syncs <master-name> <nums>：

表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据

 

sentinel failover-timeout <master-name> <milliseconds>：

故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

 

sentinel notification-script <master-name> <script-path> ：

配置当某一事件发生时所需要执行的脚本

 

sentinel client-reconfig-script <master-name> <script-path>：

客户端重新配置主节点参数脚本

Inicie uma instância redis com um mestre e dois escravos, configure sentinelas e demonstre a replicação mestre-escravo normal

1	Crie um novo arquivo de configuração redis6379.conf na máquina 169. Para corresponder a este caso, defina a senha de acesso do item masterauth para 111111. Caso contrário, um erro pode ser relatado posteriormente master_link_status:down
2	Crie um novo arquivo de configuração redis6380.conf na máquina 172, defina a réplica de <masterip> <masterport>
3	Crie um novo arquivo de configuração redis6381.conf na máquina 173, defina a réplica de <masterip> <masterport>

Com base em um mestre e dois escravos configurados no capítulo anterior, o host redis6379.conf precisa ser alterado

redis6379.conf

6379 pode se tornar um escravo no futuro, você precisa definir uma senha para acessar o novo host, defina a senha de acesso do item masterauth para 111111

redis 6380.conf

O endereço IP específico e a senha devem ser modificados de acordo com sua situação real local.

redis 6381.conf

Iniciar um mestre e dois escravos

6379.conf
    redis-server /myredis/redis6379.conf 
    redis-cli -a 111111 -p6379
 
6380.conf
    redis-server /myredis/redis6380.conf 
    redis-cli -a 111111 -p 6380
 
6381.conf
    redis-server /myredis/redis6381.conf 
    redis-cli -a 111111-p 6381

iniciar sentinela

redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel

Ver informações do sentinela

Verifique as informações de replicação mestre-escravo e descubra se tudo está normal

O host está inoperante, verifique o log

Desligue o servidor redis manualmente e o host simulado desliga

Verificamos as alterações do escravo depois que o mestre desliga

Problemas que podem surgir:

Uma certa explicação do tubo quebrado:

Conheça o cano quebrado	Pipe significa pipeline e, dentro do pipeline, há um fluxo de dados, geralmente dados lidos de um arquivo ou soquete de rede. Quando o tubo é fechado repentinamente na outra extremidade, os dados são interrompidos repentinamente, o que é interrompido. Para o soquete, Provavelmente a rede foi desconectada ou o processo na outra ponta travou
Resolva o problema	Na verdade, quando ocorre a exceção, ela não tem muito impacto no servidor. Este erro pode ser causado por um cliente que encerrou o processo repentinamente
Resumo Tubo Quebrado	Essa exceção é que o cliente leu o tempo limite e fechou a conexão. Nesse momento, o servidor envia ao cliente Uma exceção de canal quebrado ocorre quando uma conexão desconectada grava dados!

Para resumir, o desligamento do mestre tem um impacto transitório no escravo. Não entre em pânico ao encontrar esse tipo de problema, basta digitar novamente o mesmo comando.

Continue para ver as informações da cópia

6380

6381

Descobrimos que 6381 se tornou o host

Comparar arquivos de configuração

velho mestre vim redis6379.conf

redis6379 offline

vim redis6380.conf

novo mestre vim redis6381.conf

chegamos a conclusão:

Sentinel26379.log, sentinel26380.log e sentinel26381.log neste artigo serão alterados dinamicamente durante a operação

Na chave mestre-escravo, o conteúdo do arquivo redis###.conf será alterado automaticamente

Além disso, vários mestres podem ser monitorados no Sentinel, um por linha

Processo operacional e princípio de seleção do Sentinel

Quando um mestre em uma configuração mestre-escravo falha, o Sentinel pode eleger um novo mestre para assumir o trabalho do mestre original, e outros servidores redis na configuração mestre-escravo apontam automaticamente para o novo mestre para sincronizar dados. Geralmente, é recomendado usar um número ímpar de sentinelas para evitar que uma determinada sentinela não consiga se conectar ao mestre e cause uma troca acidental.

Offline subjetivo e offline objetivo

SDOWN off-line subjetivo

1. SDOWN é o estado do mestre detectado subjetivamente por uma única sentinela. Do ponto de vista da sentinela, se nenhuma resposta legal for recebida dentro de um certo período de tempo após o envio da pulsação do PING, a condição SDOWN 2 é atendida. O
down -after-miliseconds no arquivo de configuração sentinela define o período de tempo para julgar off-line subjetivo

O chamado subjetivamente inativo (Subjectively Down, referido como SDOWN) refere-se ao julgamento off-line feito por uma única instância do Sentinel ao servidor, ou seja, um único sentinela pensa que um serviço está off-line (pode ser que a assinatura não possa ser recebido, a rede entre eles não está conectada, etc. e outros motivos). Offline subjetivo significa que, se o servidor não responder ao comando PING ou retornar uma mensagem de erro dentro de um determinado número de milissegundos em [sentinel down-after-milliseconds], o Sentinel irá subjetivamente (unilateralmente) considerar o mestre indisponível Sim , o (╥﹏╥)o

sentinela inativa após milissegundos <masterName> <timeout>

Indica o intervalo de tempo para que o mestre seja considerado inválido pela instância sentinela atual. Essa configuração é, na verdade, uma base para off-line subjetivo

Quanto tempo o mestre não retorna informações válidas ao Sentine, considera-se que o mestre está subjetivamente offline. Ou seja, se o redis-servevr não for contatado por muito tempo, considera-se que o redis-server entrou no estado SDOWN.

ODOWN objetivo off-line

ODOWN requer um certo número de sentinelas, e vários sentinelas podem chegar a um consenso para considerar que um mestre está objetivamente inoperante

O significado dos quatro parâmetros:

masterName é um identificador distinto para uma combinação mestre+escravo (um conjunto de sentinelas pode monitorar vários grupos de combinações mestre+escravo)

O parâmetro quorum é uma base para objetivo offline , o quorum/quórum de votos

Isso significa que pelo menos os sentinelas de quorum acham que o mestre está com defeito antes de ficar offline e fazer o failover do mestre. Porque, às vezes, um nó sentinela pode não conseguir se conectar ao mestre devido à sua própria rede, mas o mestre não está com defeito neste momento, portanto, isso requer que vários sentinelas concordem que o mestre tem um problema antes de prosseguir para a próxima etapa Isso garante imparcialidade e alta disponibilidade.

Sentinela do líder eleitoral (escolha o rei dos soldados da sentinela)

Quando o nó mestre é considerado objetivamente offline, cada nó sentinela negociará e o município elegerá um nó sentinela líder e o nó líder executará failover (migração de falha)

O algoritmo Raft seleciona o nó líder

Todos os Sentinelas que monitoram o nó mestre podem ser eleitos como o líder. O algoritmo usado para a eleição é o algoritmo Raft; a ideia básica do algoritmo Raft é o primeiro a chegar, primeiro a ser servido: ou seja, em uma rodada de eleições , Sentinela A envia uma mensagem a B para se tornar o líder. , se B não concordou com outras sentinelas, ele concordará com A como líder

registrar mudanças

O rei dos soldados ativa o failover e elege um novo mestre

novo senhor entronizado

Um candidato escravo torna-se o novo mestre para selecionar uma nova regra mestre . No arquivo redis.conf,
sob a condição de que os nós escravos restantes estejam íntegros, o nó escravo com a prioridade mais alta prioridade escravo ou prioridade réplica (quanto menor o número , maior a prioridade)

Copie o nó escravo com a maior posição de deslocamento (aquela com o maior número de registros no log) e
o nó escravo com o menor Run ID, ou seja, em ordem lexicográfica, código ASCII

Todos os funcionários abaixaram a cabeça, uma vez que o imperador e os cortesãos reconheceram novamente o chefe

Execute o comando slaveofnoone para tornar o nó escravo selecionado o novo nó mestre e use o comando slaveof para tornar outros nós seus nós escravos. O líder do Sentinel executará a operação slaveofnoone no novo
mestre eleito e o promoverá ao nó mestre
Sentinela O líder envia comandos para outros escravos, tornando os escravos restantes os escravos do novo nó mestre

O velho mestre adora, e o velho mestre tem que ser persuadido quando ele voltar

Defina o antigo mestre que estava off-line antes como o nó escravo do novo mestre recém-eleito. Quando o antigo mestre ficar online novamente, ele se tornará o nó escravo do novo mestre. O líder sentinela degradará o mestre original para escravo e retomará trabalho normal.

Sugestões para usar o Sentinel

O número de nós sentinelas deve ser múltiplo e a própria sentinela deve ser agrupada para garantir alta disponibilidade

O número de linfonodos sentinela deve ser um número ímpar

A configuração de cada nódulo sentinela deve ser consistente

Se o nó sentinela for implantado em um contêiner como o Docker, preste atenção ao mapeamento de porta correto

Cluster do Sentinel + replicação mestre-escravo não garante perda zero de dados

[noções básicas do redis] Sentinela

conceito