Seconds_Behind_Master от SHOW SLAVE STATUS считается ненадежным показателем задержки Slave. mk-heartbeat часто предлагается в качестве надежной альтернативы.
Теперь mk-heartbeat даже не требует, чтобы Slave был запущен.
http://www.maatkit.org/doc/mk-heartbeat.html
Отрывок:
mk-heartbeat - это система мониторинга задержки репликации MySQL и PostgreSQL, состоящая из двух частей, которая не требует работы ведомого устройства (другими словами, она не полагается на SHOW SLAVE STATUS в MySQL).
Насколько я понимаю, вы создаете БД / таблицу на Мастере, запускаете mk-heartbeat с помощью --update следующим образом:
./mk-heartbeat -D heart --table beat -u heartbeat -p XXXXXXXXX --update -h 192.168.2.80
А затем на Slave вы указываете mk-heartbeat на DB / table на Master (т.е. вы выполняете оператор GRANT на Master, чтобы предоставить привилегии Slave) и запускаете с --monitor следующим образом:
./mk-heartbeat -D heart --table beat -u heartbeat_slave -p XXXXXXXXX --monitor -h 192.168.2.80
Я сделал именно это, и даже при многократном обновлении 2,8 млн строк в таблице зарплат сотрудников образца MySQL (которая создает задержку Slave, по крайней мере, в соответствии с ненадежным Seconds_Behind_Master), я никогда не вижу изменения mk-heartbeat --monitor с:
0s [ 0.00s, 0.00s, 0.00s ]
Возможно, дело в том, что я не произвел достаточной задержки и, согласно документации mk-heartbeat, события репликации распространяются менее чем за полсекунды, и я могу ожидать появления нулевой секунды задержки:
mk-heartbeat имеет разрешение в одну секунду. Это зависит от того, что часы на главном и подчиненном серверах тесно синхронизируются через NTP. Проверки --update происходят на грани секунды, а проверки --monitor происходят посередине между секундами. Пока часы серверов не сильно искажены, а события репликации распространяются менее чем за полсекунды, mk-heartbeat сообщит о нулевой секунде задержки.
(Часы моих серверов используют NTP и синхронизированы.)
Но Seconds_Behind_Master отстает на сотни секунд, поэтому я бы подумал, что они не распространяются менее чем за полсекунды, поэтому я все еще не уверен, получаю ли я точное представление об утилите mk-heartbeat или нет.
Хотелось бы услышать мнение любого, кто развернул этот инструмент для мониторинга своей репликации MySQL.
Заранее спасибо.
Ура
Вы близки, но ваша проблема в том, что оба экземпляра указывают на мастера. Вам нужно, чтобы один экземпляр обновлял ведущее устройство каждую секунду, а второй экземпляр читал ведомое устройство каждую секунду.
Также обратите внимание, что его вообще не нужно запускать на реальных серверах баз данных, он использует обычное клиентское соединение mysql. Я запускаю свой с сервера кактусов. Вот мой очищенный /etc/rc.local для примера:
/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
Вот что я делаю:
mk-heartbeat -D maatkit -u maatkit -p pass --update -h master
mk-heartbeat -D maatkit -u maatkit -p pass -h slave --monitor
Когда я запускаю приведенный выше фрагмент вывода,
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 ]
Цифры просто медленно растут.
Нужно ли реплицировать таблицу контрольных сигналов на ведомое устройство? Это то, что мне не хватает?