O comando que você postou não parece 100% correto para mim. No meu sistema, lê-se:
haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf $(cat /var/run/haproxy.pid)
Você digitou incorretamente o valor da última opção -sf
.
Eu estava procurando uma solução para recarregar o haproxy. Eu tenho um servidor nginx em execução que passa solicitações para Haproxy e às vezes eu recarregar a configuração Haproxy. Mas estou observando que no momento de recarregar todas as conexões existentes estão sendo cortadas e a fila de back-end do haproxy mostra 0 solicitações (obtidas de estatísticas de soquete do haproxy).
Estou usando o método mencionado em vários posts do blog e a documentação do haproxy sobre o assunto:
Recarregue:
haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf (</var/run/haproxy.pid)
Iniciar:
haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid
Será grato se alguém puder sugerir qualquer solução. Abaixo está o meu arquivo de configuração haproxy
global
maxconn 64000
ulimit-n 200000
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
spread-checks 5
stats socket /etc/haproxy/stats
defaults
log global
mode http
balance roundrobin
maxconn 64000
option abortonclose
option httpclose
retries 3
option redispatch
timeout client 30000
timeout connect 30000
timeout server 30000
stats enable
stats uri /haproxy?stats
stats realm Haproxy Statistics
stats auth haproxy:stats
timeout check 5000
O comando que você postou não parece 100% correto para mim. No meu sistema, lê-se:
haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf $(cat /var/run/haproxy.pid)
Você digitou incorretamente o valor da última opção -sf
.
Isso pode ser esperado dependendo da sua metodologia de teste. Embora, como mencionado acima, você também parece estar perdendo um $
perto do fim do seu comando de recarga?
Quando o HAProxy faz o 'reload' inicia um novo processo HAProxy, envia os dados da session para um soquete do domínio unix do primeiro processo para o segundo processo, o primeiro processo é desvinculado das portas TCP escutando, e o segundo processo se liga. O primeiro processo termina então. Portanto, eles não compartilham memória em nenhum estágio e não parecem sincronizar os descritores de arquivo (a partir de meus próprios testes, de qualquer maneira). Portanto, o ponto principal do recarregamento é que as tabelas de persistência (como o hash baseado em cookie) são mantidas para que o cliente se reconecte ao servidor de backend necessário. No entanto, ele deve ser gracioso no sentido de que as conexões são drenadas do primeiro processo, e não imediatamente descartadas.
Se você observar a sua tabela de processos enquanto estiver realizando a recarga, deve observar o acima, a menos que as coisas tenham mudado desde que eu testei (alguns meses atrás).
Tags load-balancing haproxy