Ajude-me a entender o mk-heartbeat

Question

Seconds_Behind_Master do SHOW SLAVE STATUS é considerado uma medida não confiável de atraso do escravo. O mk-heartbeat é frequentemente oferecido como uma alternativa confiável.

Agora o mk-heartbeat nem precisa do escravo para ser executado.

link

Trecho:

mk-heartbeat is a two-part MySQL and PostgreSQL replication delay monitoring system that doesn't require the slave to be working (in other words, it doesn't rely on SHOW SLAVE STATUS on MySQL).

Então, meu entendimento é que você cria um banco de dados / tabela no mestre, execute o mk-heartbeat com --update da seguinte forma:

./mk-heartbeat -D heart --table beat -u heartbeat -p XXXXXXXXX --update -h 192.168.2.80

E então no Escravo você aponta mk-heartbeat no DB / table no Master (ou seja, você faz uma instrução GRANT no Master para dar privilégios Slave) e roda com --monitor da seguinte forma:

./mk-heartbeat -D heart --table beat -u heartbeat_slave -p XXXXXXXXX --monitor -h 192.168.2.80

Eu fiz exatamente isso e até mesmo atualizando repetidamente as linhas de 2.8M + na tabela de salários de funcionários do MySQL (que cria o atraso do escravo, pelo menos de acordo com o não confiável Seconds_Behind_Master) Eu nunca vejo o mk-heartbeat --monitor mudar de:

0s [  0.00s,  0.00s,  0.00s ]

Talvez seja o caso de eu não ter produzido lag suficiente e que, de acordo com os documentos do mk-heartbeat, os eventos de replicação estão se propagando em menos de meio segundo e posso esperar zero segundos de atraso:

mk-heartbeat has a one-second resolution. It depends on the clocks on the master and slave servers being closely synchronized via NTP. --update checks happen on the edge of the second, and --monitor checks happen halfway between seconds. As long as the servers' clocks aren't skewed much and the replication events are propagating in less than half a second, mk-heartbeat will report zero seconds of delay.

(os relógios dos meus servidores estão usando NTP e estão sincronizados.)

Mas Seconds_Behind_Master está centenas de segundos atrás, então eu acho que eles não estão se propagando em menos de meio segundo, então ainda não tenho certeza se estou obtendo uma visão precisa do utilitário mk-heartbeat ou não.

Adoraria ouvir de qualquer pessoa que tenha implementado essa ferramenta para monitorar sua replicação do MySQL.

Obrigado antecipadamente.

Felicidades

    

Answer 1

Você está próximo, mas seu problema é que você tem as duas instâncias apontando para o mestre. O que você quer é uma instância atualizando o mestre a cada segundo, e a segunda instância lendo o escravo a cada segundo.

Observe também que ele não precisa ser executado nos servidores reais de banco de dados, ele usa uma conexão regular do cliente mysql. Eu corro o meu do meu servidor cacti. Aqui está o meu /etc/rc.local higienizado para um exemplo:

/usr/bin/mk-heartbeat -D maatkit -u maatkit -paardvark --update -h sql-master.fake.net --daemonize
/usr/bin/mk-heartbeat -D maatkit -u maatkit -paardvark -h sql-slave.fake.net --monitor --file /tmp/sql-slave.heartbeat --daemonize

    

Answer 2

Aqui está o que estou fazendo:

mk-heartbeat -D maatkit -u maatkit -p pass --update -h master
mk-heartbeat -D maatkit -u maatkit -p pass -h slave --monitor

Quando executo o código acima, o snippet de saída é

1618s [ 53.92s, 10.78s,  3.59s ]
1619s [ 80.90s, 16.18s,  5.39s ]
1620s [ 107.90s, 21.58s,  7.19s ]
1621s [ 134.92s, 26.98s,  8.99s ]
1622s [ 161.95s, 32.39s, 10.80s ]
1623s [ 189.00s, 37.80s, 12.60s ]
1624s [ 216.07s, 43.21s, 14.40s ]
1625s [ 243.15s, 48.63s, 16.21s ]

Os números apenas aumentam lentamente.

A tabela de pulsação precisa estar sendo replicada para o escravo? É isso que eu sinto falta?