O Redis Sentinel é um sistema distribuído.Você pode executar vários processos do Sentinel (progresso) em uma arquitetura.Esses processos usam protocolos de fofocas para receber informações sobre se o servidor principal está offline e protocolos de votação (protocolos de contrato) ) Para decidir se deseja executar o failover automático e qual servidor escravo escolher como o novo servidor mestre.
Embora o Redis Sentinel seja lançado como um arquivo executável separado redis-sentinel, na verdade, é apenas um servidor Redis executando em um modo especial.Você pode iniciar o Redis dando a opção --sentinel ao iniciar um servidor Redis normal Sentinela.
O sistema Sentinel é usado para gerenciar vários servidores Redis (instância) .O sistema executa as três tarefas a seguir:
1. Monitoramento (monitoramento): O Sentinel verifica constantemente se o servidor mestre e o servidor escravo estão funcionando normalmente.
2. Notificação: quando há um problema com um servidor Redis monitorado, o Sentinel pode enviar uma notificação ao administrador ou a outros aplicativos por meio da API.
3. Failover automático: quando um servidor mestre falhar, o Sentinel iniciará uma operação de failover automático, atualizará um dos servidores mestre com falha do servidor escravo para um novo servidor mestre e permitirá que o mestre com falha Os outros servidores escravos do servidor são alterados para copiar o novo servidor mestre; quando o cliente tenta se conectar ao servidor mestre com falha, o cluster também retornará o endereço do novo servidor mestre ao cliente, para que o cluster possa usar o novo servidor mestre para substituir o servidor com falha.
Configuração
Quando o mestre está inoperante e o escravo substitui o mestre para se tornar o novo mestre, o mestre inativo se tornará automaticamente um escravo após o início.Ele é o mesmo que o modo de mestre duplo do Mysql. arquivo de configuração sentinel.conf.
mkdir -p / usr / local / redis mkdir -p / usr / local / redis / 6379 mkdir -p / usr / local / redis / 6380 mkdir -p / usr / local / redis / redis_cluster
Posicionamento principal
vim redis_6379.conf
daemonize yes pidfile /usr/local/redis/6379/redis_6379.pid porta 6379 tcp-backlog 128 tempo limite 0 tcp-keepalive 0 aviso de nível de logfile "" bancos de dados 16 " salva 16 1 900 # ## save save 300 10 save 60 10000 interrupções de gravação -on-bgsave-error sim rdbcompression sim rdbchecksum sim dbfilename dump.rdb ### diretório dbfile "/ usr / local / redis / 6379" masterauth "123456" requirepass "123456" slave-serve-stale-data sim slave-read- somente sim repl-diskless-sync não repl-diskless-sync-delay 5 repl-disable-tcp-nodelay não slave-priority 100 appendonly sim appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite não auto-aof-rewrite -percent 100 100 auto-aof-rewrite-min-size 64mb aof-load-truncated sim lua-time-limit 5000 lua lenta log-mais lento que 10000 slowlog-max-len 128 latência-monitor-limite 0 eventos-espaço-chave-eventos "" hash-max-ziplist-entradas 512 hash-max-ziplist- entradas 512 hash-max-ziplist-value 64 list-max-ziplist-entradas 512 list -max-ziplist-value 64 set-max-intset-entradas 512 zset-max-ziplist-entradas 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 activeerehashing yes cliente-saída-buffer-limite normal 0 0 0 cliente-saída-buffer-limite escravo 256mb 64mb 60 cliente-saída-buffer-limite pubsub 32mb 8mb 60mb hz 10 aof-rewrite-incremental-fsync yes
vim sentinel_1.conf
Configuração de arquivo do Sentinel
dir da porta 6000 "/ usr / local / redis / sentinel" # daemonize sim modo protegido sem arquivo de log "/usr/local/sentinel/sentinel.log"
De configuração
vim redis_6380.conf
daemonize yes pidfile "/usr/local/redis/6380/redis_6380.pid" porta 6380 tcp-backlog 128 timeout 0 tcp-keepalive 0 aviso de nível de log arquivo de log "" bancos de dados 16 " salvar 900 1 salvar 300 10 salvar 60 10000 parar de gravar -bgsave-error sim rdbcompression sim rdbchecksum sim dbfilename "dump.rdb" dir "/ usr / local / redis / 6380" masterauth "123456" requirepass "123456" escravo-servir-obsoleto-dados sim escravo-somente leitura sim repl-diskless-sync não repl-diskless-sync-delay 5 repl-disable-tcp-nodelay nenhum slave-prioridade 100 appendonly sim appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-reescrever nenhuma auto-AOF-rewrite-porcentagem 100 auto-AOF-rewrite-min-size 64mb AOF-truncado carga sim lua-prazo 5000 slowlog-log- mais lento que 10000 slowlog-max-len 128 latência-monitor-limite 0 notificações-chaves-espaço-eventos "" hash-max-ziplist-entradas 512 hash-max-ziplist-value 64 lista-max-ziplist-entradas 512 list-max -ziplist-value 64 set-max-intset-entradas 512 zset-max-ziplist-entradas 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 activeerehashing yes client-output-buffer-limit normal 0 0 0 escravo de limite de buffer de saída do cliente 256mb 64mb 60 pubsub de limite de buffer de saída do cliente 32mb 8mb 60 hz 10 aof-rewrite-incremental-fsync yes
vim sentinel_2.conf
#sentinelportport 6000 # Caminho de trabalho, preste atenção ao caminho e não repita o diretório "/ usr / local / sentinel" # Daemonize sim no modo protegido não # # Especifique o nome do arquivo de log logfile "/ usr / local / sentinel / sentinel. log "
Nota:
1. O aplicativo se conecta à porta de sentinela e à cópia principal específica, especificando um nome mestre diferente.
2. No arquivo de configuração da sentinela, você só precisa configurar o ip e a porta da cópia mestre na cópia mestre-escravo.Quando o mestre e o escravo alternarem, a sentinela modificará automaticamente a cópia mestre ip no arquivo de configuração da sentinela para a nova cópia mestre ip.
3. Um arquivo de configuração sentinela pode ser configurado para monitorar simultaneamente a replicação mestre-escravo múltipla.
4. Um único sentinela pode ser usado para o monitoramento de falhas mestre-escravo, mas se houver apenas um processo sentinela, se esse processo estiver errado ou a rede estiver bloqueada, o comutador mestre-escravo do cluster redis não será alcançado (problema de ponto único); <quorum > Este número representa o número de votos 2. Quando duas sentinelas acham que um mestre está indisponível, ele acionará um failover para realmente pensar que o mestre não está disponível. (Os clusters do Sentinel no cluster do sentinel também se comunicam por meio do protocolo de fofocas); portanto, a configuração razoável deve ser iniciar vários processos do sentinel ao mesmo tempo e é melhor iniciar em servidores diferentes.
5. Observe que as necessidades do mymaster são únicas em todo o ambiente de rede, e as sentinelas estabelecerão automaticamente um relacionamento de associação através do nome de usuário, desde que o ambiente de rede esteja interligado.
Iniciar redis
1. Mestre e escravo devem começar
src / redis-server redis.conf
2. Faça logon no 6380 para estabelecer um relacionamento mestre-escravo
redis-cli -p 6380 escravo de 192.168.137.40 6379
Configurar o Sentinel
A sentinela principal e a escrava devem ser iniciadas e também podem ser iniciadas através do redis-server, como "redis-server sentinel.conf --sentinel"
1. Inicie o Sentinel
src/redis-sentinel sentinel.conf2. Faça login no sentinela (os dois sentinelas precisam fazer login para executar), adicione informações de monitoramento mestre e escravo
redis-cli -p 6000
sentinel monitor mymaster 192.168.137.40 6379 2
sentinel set mymaster down-after-milliseconds 5000
sentinel set mymaster failover-timeout 15000
sentinel set mymaster auth-pass 123456Iniciar tratamento de erros
Erro 1:
AVISO overcommit_memory está definido como 0! A gravação em segundo plano pode falhar em condições de pouca memória. Para corrigir esse problema, adicione 'vm.overcommit_memory = 1' ao /etc/sysctl.conf e, em seguida, reinicie ou execute o comando 'sysctl vm.overcommit_memory = 1' para que isso entre em vigor.
Duas soluções (overcommit_memory)
1. echo "vm.overcommit_memory = 1"> /etc/sysctl.conf ou vi /etcsysctl.conf e, em seguida, reinicie para reiniciar a máquina
2. echo 1> / proc / sys / vm / overcommit_memory entra em vigor sem iniciar a máquina
Descrição do parâmetro Overcommit_memory:
Defina a estratégia de alocação de memória (opcional, configurada de acordo com a situação real do servidor)
/ proc / sys / vm / overcommit_memory
Valores opcionais: 0, 1, 2.
0, significa que o kernel verificará se há memória disponível suficiente para o processo usar; se houver memória disponível suficiente, o aplicativo de memória será permitido; caso contrário, o aplicativo de memória falhará e retornará o erro ao processo do aplicativo.
1, indica que o kernel permite que toda a memória física seja alocada, independentemente do status atual da memória.
2, representa o kernel permite a distribuição sobre toda a memória física e swap espaço de memória soma
Nota: Redis quando os dados de despejo vai desembolsar um processo filho, processo filho teoricamente memória ocupada e pai é o mesmo, como o pai ocupado A memória é 8 G. Nesse momento, também é necessário alocar 8 G de memória para a criança. Se a memória não puder ser fornecida, geralmente fará com que o tempo de inatividade do servidor redis ou a carga de E / S seja muito alto e a eficiência diminuirá. Portanto, a estratégia de alocação de memória mais otimizada aqui deve ser definida como 1 (indicando que o kernel permite que toda a memória física seja alocada, independentemente do status atual da memória).
Overcommit e OOM também estão envolvidos aqui.
O que é Overcommit e OOM
No Unix, quando um processo do usuário usa a função malloc () para solicitar memória, se o valor de retorno for NULL, o processo saberá que atualmente não há espaço disponível na memória e fará o trabalho de processamento correspondente. Muitos processos imprimirão uma mensagem de erro e sairão.
O Linux usa outro método de processamento e responde "sim" à maioria dos pedidos de memória, para poder executar programas cada vez maiores. Porque depois de solicitar a memória, a memória não será usada imediatamente. Essa técnica é chamada Overcommit.
Quando a memória é insuficiente, o OOM killer (OOM = falta de memória) ocorrerá. Ele escolherá interromper alguns processos (processos no modo de usuário, não threads do kernel) para liberar memória.
Estratégia
de supercomprometimento Existem três estratégias para supercomprometimento no Linux (Documentation / vm / overcommit-accounting):
0. Estratégia heurística. O comprometimento excessivo razoável será aceito e o comprometimento excessivo será rejeitado.
1. Qualquer comprometimento excessivo será aceito.
2. Quando a memória alocada pelo sistema exceder swap + N% * RAM física (N% é determinado por vm.overcommit_ratio), a confirmação será rejeitada.
A estratégia de confirmação excessiva é definida por vm.overcommit_memory.
A porcentagem de confirmação excessiva é definida por vm.overcommit_ratio.
Echo 2 #> / proc / sys / vm / overcommit_memory
# echo 80> / proc / sys / vm / overcommit_ratio
quando ocorrer o oom-killer, linux vai escolher qual processo para matar o
processo de seleção da função é a função oom_badness (em mm / oom_kill .c), esta função calculará os pontos de cada processo (0 ~ 1000).
Quanto maior o número de pontos, maior a probabilidade desse processo ser morto.
Os pontos de cada processo estão relacionados ao oom_score_adj e oom_score_adj pode ser definido (-1000 no mínimo, 1000 no máximo).
Erro 2:
AVISO: A configuração de backlog TCP de 511 não pode ser imposta porque / proc / sys / net / core / somaxconn está definido como o valor mais baixo de 128.
echo 511 > /proc/sys/net/core/somaxconnErro 3:
16433: X 12 Jun 14: 52: 37.734 * Número máximo de arquivos abertos aumentado para 10032 (foi originalmente definido para 1024).
O padrão do Linux recém-instalado é de apenas 1024. Quando a carga é grande, erro: muitos arquivos abertos geralmente aparecem
ulimit -a: Use para visualizar todos os valores limite do sistema atual
vim /etc/security/limits.confAdicione no final do arquivo
* soft nofile 65535
* hard nofile 65535Execute su ou feche novamente o usuário da conexão e, em seguida, execute ulimit -a para visualizar o resultado modificado.
Mecanismo de failover
1. Após iniciar o cluster, o programa de cluster incluirá a configuração do mestre de conexão no arquivo redis da biblioteca escrava por padrão.
# Generated by CONFIG REWRITE
slaveof 192.168.137.40 63792. Após iniciar o cluster, o programa cluster adicionará as informações do cluster ao arquivo master-slave sentinel.conf por padrão
Principal:
porta 26379 dir "/ usr / local / redis-6379" # daemonize yes # arquivo de log "./sentinel.log" monitor sentinela mymaster 192.168.137.40 6379 1 failin sentinela após milissegundos mymaster 5000 failover sentinela -timeout mymaster 18000 sentinela auth-pass mymaster 123456 # Gerado por CONFIG REWRITE sentinela config-época mymaster 0 sentinela líder-época mymaster 1 sentinela-escravo conhecido mymaster 192.168.137.40 6380 sentinela conhecido por sentinela mymaster 192.168.137.40 26380 c77c5f64aaad0137a228875e531c7127ceeb5c3f sentinela corrente época 1
De:
port #sentinel Porto 26380 # caminho de trabalho dir "/ usr / / Redis-6380 local" # modo daemon daemonize sim # especificado arquivo de log nome arquivo de log "./sentinel.log" # sentinela configuração mestre de vigilância, mestre-escravo, como em 6379 se tornará a porta principal atual ao executar o comutador mestre-escravo Monitor do Sentinel mymaster 192.168.137.40 6379 1 # Quanto tempo o mestre ou escravo (padrão 30 segundos) não pode ser usado e marcado como estado s_down. sentinel abaixo de milissegundos mymaster 5000 #Se o sentinel falhar ao concluir a operação de failover dentro deste valor de configuração (ou seja, o mestre / escravo alterna automaticamente quando ocorre uma falha), considera-se que o failover falhou neste momento. sentinel failover-timeout mymaster 18000 #Definir a senha de verificação de mestre e escravo sentinel auth-pass mymaster 123456 #O programa Sentinel adicionou automaticamente a parte # Gerada por CONFIG REWRITE sentinel config-epoch mymaster 0 sentinel leader-epoch mymaster 1 ### indica o ip e a porta da biblioteca escrava do cluster atual, o valor será alterado quando o comutador mestre-escravo sentinela conhecido-escravo mymaster 192.168.137.40 6380 ### Além do sentinela atual, que outro sentinela sentinela conhecido-sentinela mymaster 192.168.137.40 26379 7a88891a6147e202a53601ca16a3d438e9d55c9d época atual sentinela 1
Simular falha principal
[root @ monitor redis-6380] # ps -ef | grep redis raiz 4171 1 0 14:20? 00:00:15 / usr / local / redis-6379 / src / redis-server *: 6379 raiz 4175 1 0 14:20? 00:00:15 / usr / local / redis-6380 / src / redis-server *: 6380 root 4305 1 0 15:28? 00:00:05 / usr / local / redis-6379 / src / redis-sentinel *: 26379 raiz [sentinela] 4306 1 0 15:28? 00:00:05 / usr / local / redis-6380 / src / redis-sentinel *: 26380 [sentinela] raiz 4337 4144 0 15:56 pts / 1 00:00:00 grep redis [root @ monitor redis-6380] # kill -9 4171 [root @ monitor redis-6380] # ps -ef | grep redis raiz 4175 1 0 14:20? 00:00:15 / usr / local / redis-6380 / src / redis-server *: 6380 root 4305 1 0 15:28? 00:00:05 / usr / local / redis-6379 / src / redis-sentinel *: 26379 raiz [sentinela] 4306 1 0 15:28? 00:00:05 / usr / local / redis-6380 / src / redis-sentinel *: 26380 raiz [sentinela] 4339 4144 0 15:56 pts / 1 00:00:00 grep redis [raiz no monitor redis-6380] #
Você pode ver no arquivo de configuração da sentinela que a biblioteca principal atual foi alterada
Sumário
As portas 26379 e 26380 do Redis sentinel não podem ser conectadas usando o software cliente, mas podem ser conectadas usando o programa.O software cliente pode conectar-se diretamente apenas às portas 6379 e 6380. Use o sentinela para monitorar quando o mestre falhar, ele alternará automaticamente o escravo para mestre e, quando o mestre iniciar, ele se tornará um escravo. Há casos em que outros só configuraram um único sentinel 26379, o que não pode garantir a alta disponibilidade do próprio programa sentinela.
A descrição acima é o conteúdo detalhado do método do modo Redis Sentinel para realizar a comutação de falhas mestre-escravo
Para mais conteúdo de aprendizagem, visite: