В конфигурации высокой доступности (HA) главного и подчиненного MySQL важно постоянно следить за работоспособностью главного и подчиненного серверов, чтобы вы могли обнаруживать потенциальные проблемы и предпринимать корректирующие действия. В этом сообщении мы расскажем о некоторых базовых проверках работоспособности, которые вы можете выполнять на главном и подчиненном узлах MySQL, чтобы убедиться в правильности настройки. Программа или сценарий мониторинга должны предупреждать инфраструктуру высокой доступности в случае неудачной проверки работоспособности, что позволяет инфраструктуре высокой доступности предпринимать корректирующие действия для обеспечения доступности службы.
Вам также могут понравиться: плюсы и минусы типов репликации MySQL
Проверка работоспособности главного сервера MySQL
Мы рекомендуем, чтобы ваша главная программа мониторинга MySQL или сценарии запускались с частыми интервалами Предполагая, что скрипт мониторинга работает на том же сервере, что и ваш сервер MySQL, вы можете проверить следующее:
Убедитесь, что служба MySQL работает
Это можно сделать с помощью простой команды, например:
MySQL
xxxxxxxxxx
1
> pgrep mysqldOR
2
>service mysqld status
Убедитесь, что вы можете подключиться к MySQL и сделать простой запрос
Мы рекомендуем иметь короткий тайм-аут для этих команд, чтобы вы могли быстро определить, не отвечает ли MySQL. Это может быть достигнуто с помощью звонка, как:
/usr/bin/timeout 5 mysql -u testuser -ptestpswd -e 'select * from mysql.test’
Обязательно проверьте выходное значение вышеуказанной команды:
Джава
xxxxxxxxxx
1
Exit value=0 ⇒ Success
2
Exit value=1 ⇒ Failure
3
Exit-value=124 ⇒ Timeout
Если команда истекает, это означает, что служба MySQL недостаточно отзывчива. Мы рекомендуем вам повторить попытку через некоторое время, чтобы избежать ложноотрицательных результатов. Если код завершения указывает на сбой, код возврата из MySQL сообщит нам причину сбоя. Одним из примеров сбоя является ошибка «Слишком много подключений» из MySQL, которая возникает, если число подключений к серверу превышает значение конфигурации «max_connections».
Убедитесь, что MySQL Master работает в режиме чтения-записи
Вы можете использовать следующую команду, чтобы убедиться, что мастер MySQL работает в режиме чтения-записи:
/usr/bin/timeout 5 mysql -u testuser -ptestpswd -e "SELECT @@global.read_only"
Ожидается, что мастер всегда будет работать в режиме чтения-записи, и, следовательно, значение read_only должно быть «OFF».
Также возможно объединить этот шаг с шагом 2, и вместо выполнения тестового запроса ‘select * from MySQL.test, мы можем просто выполнить запрос, чтобы получить значение read_only.
Проверка работоспособности подчиненного сервера MySQL
Вы можете запустить мониторинг ваших подчиненных MySQL с меньшей частотой по сравнению с ведущим, так как они не обрабатывают запись данных. Первые 3 шага для проверки работоспособности ведомого устройства могут быть такими же, как и для главного, за исключением того, что нам нужно убедиться, что ведомое устройство работает в режиме только для чтения — значение переменной read_only должно быть «ON» в шаге 3.
Кроме того, мы можем сделать больше проверок на ведомом устройстве, чтобы гарантировать его статус репликации, такой как:
- Раб настроен на репликацию с правого мастера.
- Связь раба с хозяином здорова.
- Подчиненный может применять полученные события мастера.
Все вышеперечисленное можно проверить с помощью команды «show slave status». Например:
MySQL
xxxxxxxxxx
1
mysql> show slave status \G; *************************** 1. row ***************************
2
Slave_IO_State: Waiting for master to send event Master_Host: 172.31.17.43
3
Master_User: repl_user Master_Port: 3306 Connect_Retry: 10 Master_Log_File:
4
mysql-bin.000001 Read_Master_Log_Pos: 7510 Relay_Log_File: relay-log.000006
5
Relay_Log_Pos: 414 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes
6
Slave_SQL_Running: Yes ******************Truncated*********************************
- Значение Master_Host указывает, что главный сервер настроен для репликации.
- Для значения Slave_IO_Running «Да» указывает, что ведомое устройство подключилось к ведущему и получает поток репликации.
- Для значения Slave_SQL_Running «Да» указывает, что приложение ведомого работает и может применить все события, полученные от мастера.
В этом посте мы обсудили несколько простых проверок, которые могут определить наличие основных проблем на главном и подчиненном серверах MySQL. В общем, механизм обнаружения сбоев в настройке высокой доступности является сложным вопросом и требует надежной структуры высокой доступности, с помощью которой следует осуществлять мониторинг работоспособности.
Дальнейшее чтение
Как настроить репликацию MySQL Master-Slave в Ubuntu 16.04