Não é possível ver os logs de servidores supostamente “inativos”

1

Temos um cluster do HA MariaDB no qual nosso balanceador de carga começou a não conseguir ver nossos nós db como on-line. Atualizamos nosso aplicativo para atingir os nós diretamente e ignorar o balanceador de carga porque não conseguimos descobrir o que está acontecendo.

configuração do haproxy

global
  log 127.0.0.1   local0
  log 127.0.0.1   local1 notice
  #log loghost    local0 info
  maxconn 4096
  #debug
  #quiet
  user haproxy
  group haproxy

defaults
  log     global
  mode    http
  retries 3
  timeout client 50s
  timeout connect 5s
  timeout server 50s
  option dontlognull
  option redispatch
  option tcplog
  balance  roundrobin

# Set up application listeners here.

listen admin
  bind 0.0.0.0:22002
  mode http
  stats uri /

listen mysql-cluster
  bind 0.0.0.0:3306
  balance roundrobin
  mode tcp
  server db1.my-domain.com XX.XX.XXX.94:3306 check
  server db2.my-domain.com XX.XX.XXX.97:3306 check
  server db3.my-domain.com XX.XX.XXX.96:3306 check
  option mysql-check user balance

O único trabalho desse balanceador de carga é equilibrar o tráfego entre os nós do db, não de quaisquer outros serviços. Eu tentei habilitar a depuração para ver a saída mais detalhada, mas não consigo encontrar nenhum erro relacionado à verificação do cluster mysql. Nos logs, verei as entradas de log completamente não relacionadas aos nós db que a configuração especifica. Aqui está um exemplo:

Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[10] : [ttl=3]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[11] : [auth=1 866db534aa49e7d727e7c41caf33020031f26b0e]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: process_status_message: bad node [prod-load-1] in message
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG: Dumping message with 12 fields
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[0] : [t=status]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[1] : [st=active]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[2] : [dt=1388]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[3] : [protocol=1]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[4] : [src=prod-load-1]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[5] : [(1)srcuuid=0x24deb20(36 27)]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[6] : [seq=a8b208]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[7] : [hg=5792730f]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[8] : [ts=58e3e4fb]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[9] : [ld=0.00 0.01 0.05 1/223 49874]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[10] : [ttl=3]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[11] : [auth=1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: process_status_message: bad node [demo-load2] in message
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG: Dumping message with 10 fields
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[0] : [t=NS_ackmsg]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[1] : [dest=demo-load2]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[2] : [ackseq=2717430]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[3] : [(1)destuuid=0x24e0780(37 28)]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[4] : [src=demo-load2]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[5] : [(1)srcuuid=0x24d5540(36 27)]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[6] : [hg=5391a40d]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[7] : [ts=58e3e4fb]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[8] : [ttl=3]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[9] : [auth=1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: process_status_message: bad node [prod-load-1] in message
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG: Dumping message with 12 fields
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[0] : [t=status]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[1] : [st=active]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[2] : [dt=1388]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[3] : [protocol=1]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[4] : [src=prod-load-1]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[5] : [(1)srcuuid=0x24e0640(36 27)]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[6] : [seq=a8b208]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[7] : [hg=5792730f]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[8] : [ts=58e3e4fb]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[9] : [ld=0.00 0.01 0.05 1/223 49874]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[10] : [ttl=3]
Apr 04 18:24:59 database-load-balancer-1 heartbeat: [4048]: ERROR: MSG[11] : [auth=1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]

O que posso fazer para descobrir por que meus nós db estão listados como "inativos"?

    
por Webnet 05.04.2017 / 18:07

2 respostas

1

Primeiro, assegure-se de ter o usuário mysql chamado "balance" em todos os seus servidores de banco de dados. Em seguida, verifique se o usuário "balance" tem o direito de se conectar a partir do endereço IP haproxy e não apenas do localhost.

Para configurar o log haproxy, faça o seguinte:

Você já configurou o recurso syslog local0 para o log haproxy na sua configuração haproxy.

...
log 127.0.0.1   local0
...

Adicione isto ao /etc/rsyslog.conf para gravar os logs em um arquivo.

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# haproxy logs
local0.*         /var/log/haproxy.log

Reinicie os serviços haproxy e rsyslog e, em seguida, verifique o /var/log/haproxy.log para as linhas como esta:

localhost haproxy[1555]: Server mysql/mysql-1 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

Este registro deve conter informações suficientes para identificar o problema.

    
por 15.04.2017 / 20:33
0

Você precisa usar a opção mysql-check com o cheque, se você usar apenas o checke MariaDB abre uma conexão e a mantém aberta até o tempo limite e você pode ficar sem conexões rapidamente. A opção mysql-check abre e fecha a conexão, mas você precisará de um usuário simulado no banco de dados que possa autenticar no banco de dados. Você pode verificar a documentação do

    
por 05.04.2017 / 18:40