Назад | Перейти на главную страницу

Мониторинг репликации MySQL

Как лучше всего контролировать подчиненное устройство, чтобы убедиться, что он

а) Все еще работает б) Не слишком далеко от хозяина

Я хотел бы предупредить по электронной почте, если он отстает, с радостью напишу сценарий или два для подключения к приложениям командной строки.

1

вы можете использовать мааткит мк-сердцебиение

2

вы можете посмотреть результат

show slave status;

запускается на подчиненном сервере sql, но время от времени Seconds_Behind_Master вызывает тревогу неточно.

3

вы можете взломать собственное решение, подобное моему - я использую его и для нагиос мониторинг и кормление Мунин графики, показывающие «секунды позади мастера».

на главном сервере у меня есть простая работа cron:

* * * * * root /usr/local/bin/repltest

где повторный тест:

#!/bin/bash
start=`date +%s`
d=0
while [ $d -lt 60 ] ; do
        echo "update repl_test set t= NOW(); " |mysql --defaults-file=/etc/mysql/debian.cnf repl_test
        sleep 3
        d=$(( `date +%s` - $start ))
done

на ведомом я контролирую значение, возвращаемое:

echo "select UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(t) from repl_test" |  mysql --defaults-file=/etc/mysql/debian.cnf -N repl_test

локальное время на всех серверах синхронизируется через ntp.

repl_test db содержит:

CREATE TABLE IF NOT EXISTS `repl_test` (`t` datetime NOT NULL) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `repl_test` (`t`) VALUES(NOW());

если вы запускаете репликацию - предлагаю вам также настроить mk-table-контрольная сумма время от времени сравнивать содержимое ваших sql-серверов.

У pQd это есть, самый простой способ - проверить «показать статус ведомого». Что касается неточности Seconds_behind_master, я хотел бы упомянуть, что значение - это разница во временной метке для оператора, считываемого из журнала реле подчиненным потоком SQL; это не связано с оценкой того, сколько времени потребуется, чтобы наверстать упущенное. Например, одно длительное обновление, выполнение которого занимает, скажем, час, приведет к тому, что ведомое устройство появится на час позже своего ведущего, но после завершения инструкции у него вполне может быть только 1 секунда работы, которую нужно выполнить. наверстать.

Кроме того, вы захотите предоставить «REPLICATION CLIENT» пользователю, от которого вы будете отслеживать, чтобы получить статус подчиненного устройства;

Очевидный ответ, как говорили другие, - использовать некоторую вариацию SHOW SLAVE STATUS. Я лично использую встроенную в Nagios программу проверки, но это потому, что я уже провожу все виды мониторинга через nagios. Однако есть одна загвоздка: SHOW SLAVE STATUS может показывать, что оба процесса запущены, а подчиненное устройство зависло. Исходя из того, что мы можем сказать (потому что у нас была проблема и мы изучили ее), проблема возникает, когда есть сетевая отрыжка некоторой продолжительности, которая слишком коротка, чтобы полностью убить подчиненное устройство, но слишком продолжительна для его восстановления должным образом. Мы придумали обходной маневр, в котором мы смотрим на временную метку последней записи в таблице, которая регулярно изменяется, и сравниваем ее между ведущим и ведомым устройством, а затем выдаем предупреждение, если оно «слишком далеко». Не идеально, и это сработает только при определенных обстоятельствах, но считайте себя предупрежденным.

Вы можете сослаться на это сообщение в блоге, в котором упоминаются все инструменты с открытым исходным кодом и коммерческие, которые показывают http://blog.webyog.com/2012/11/20/how-to-monitor-mysql-replication/

Обычно этот блог включает такие инструменты, как pt-heartbeat: удобный инструмент для отслеживания задержки ведомого устройства в реальном времени. pt-slave-restart: отслеживает и перезапускает подчиненное устройство в случае ошибки. pt-slave-find: Находит иерархию репликации подчиненных устройств. pt-table-контрольная сумма: проверяет, синхронизированы ли базы данных на ведомых устройствах с их ведущим устройством.

MySQL Enterprise Monitor: «Virtual DBA Assistant» от Oracle - это инструмент мониторинга на основе агентов, который имеет удобный веб-интерфейс. Вкладка «Replication», которая дает топологическое представление всех мастеров и их подчиненных, а также выводит SHOW SLAVE STATUS и SHOW MASTER STATUS.

Монитор и советник MONyog-MySQL: который поддерживает мониторинг и управление репликацией, включая вкладку «Репликация», которая дает топологическое представление всех мастеров и их подчиненных вместе с ПОКАЗАТЬ СОСТОЯНИЕ ПОДЧИНЕННОГО и ПОКАЗАТЬ СОСТОЯНИЕ ГЛАВНОГО.

Вам следует выполнить запрос SHOW SLAVE STATUS и убедитесь, что оба Slave_IO_Running и Slave_SQL_Running иметь ценность Yes. В противном случае ведомое устройство НЕ сможет восстановиться автоматически. Если оба Yes то репликация все еще работает, даже если возможна задержка (Seconds_Behind_Master).

Достаточно хороший инструмент rep_mon, часть Моя кошка Suite, по сути, это просто сценарий Perl в стиле третьего варианта pQd, однако он легко настраивается и хорошо протестирован. После настройки вы можете запустить его в качестве быстрого теста или запланировать его в cron для отправки электронных писем в случае возникновения проблемы.

При запуске он в основном просто выводит либо «ОК», либо ошибку. Вы также можете настроить предупреждение, если отставание в секундах достигнет определенного порога (установленного вами).

Однако, если вам нужен просто мониторинг пороговых значений, я бы предложил использовать maatkit, он работает путем фактической вставки и последующего запроса с использованием реального SQL, а не возможно неточного вывода SHOW SLAVE STATUS.

Использовать 

mysql_config_editor set --login-path=local --host=<< your slave >> --user=username --password

и

mysql_config_editor set --login-path=remote --host=<< your master >> --user=username --password

установить предопределенные значения входа в систему, чтобы избежать Предупреждение: использование пароля в интерфейсе командной строки может быть небезопасным.

Используйте их для запроса обоих серверов MySql:

  1. Сравните позицию журнала на ведущем устройстве с Exec_Master_Log_Pos на ведомом:

    master_log = $ (mysql --login-path = remote -e "показать статус мастера" | grep -v File | awk '{print $ 2}')

    slave_exec = $ (mysql --login-path = local -e "показать статус ведомого \ G" | grep Exec_Master_Log_Pos | awk '{print $ 2}')

    diff = $ (($ master_log - $ slave_exec))

  2. Проверьте статус ведомого IO, чтобы убедиться, что он работает:

    IO_Status = $ (mysql --login-path = local -e "показать статус ведомого \ G" | grep Slave_IO_Running | awk '{print $ 2}')

  3. Проверьте статус подчиненного SQL, чтобы узнать, в порядке ли он:

    SQL_Status = $ (mysql --login-path = local -e "показать статус ведомого \ G" | grep "Slave_SQL_Running:" | awk '{print $ 2}')

Затем вы можете использовать значения $ diff, $ SQL_Status и $ IO_Status для отправки предупреждений по электронной почте, если они не соответствуют определенным значениям в соответствии с вашими предпочтениями.

Вот как это сделать с помощью Zenoss: текст ссылки