Я настраиваю базу данных MySQL Master, которая реплицируется на несколько баз данных Slave.
Мой вопрос заключается в том, как лучше всего отслеживать и / или проверять актуальность ведомых баз данных и предупреждать администратора, когда возникает ошибка, приводящая к остановке репликации.
Я искал инструменты для мониторинга, но не нашел ничего подходящего.
Кроме того, каковы наилучшие методы тестирования синхронизации между ведомыми устройствами. Есть ли что-нибудь вроде модульного тестирования для репликации db?
Прошу прощения, если мое невежество в этом вопросе кого-то обидит.
Мой вопрос в том, как лучше всего отслеживать и / или проверять актуальность ведомых баз данных,
Для простого тестирования вставьте / обновите данные на ведущем устройстве и убедитесь, что они реплицируются на ведомые устройства.
Но для проверки согласованности pt-table-контрольная сумма это то, что вы ищете.
Например:
pt-table-checksum localhost --empty-replicate-table --databases db --nocheck-replication-filters --replicate percona.checksums > /var/log/pt-table-checksum.log 2>&1
и это предупредит администратора об ошибке, вызывающей остановку репликации.
Если вы используете Nagios, check_mysql_health плагин может помочь контролировать статус ведомого (запущен или нет). Но чтобы следить за согласованностью, взгляните на pmp-check-pt-table-контрольная сумма плагин.
Не пропустите pt-table-sync если у вас есть несоответствие:
pt-table-sync -v --print --sync-to-master h=localhost,D=db,t=table
pt-table-sync -v --execute --sync-to-master h=localhost,D=db,t=table
Имейте в виду, что вам, вероятно, следует использовать --print вариант первый.
Большая проблема с репликацией - это проверка
1, 3 и 4 могут быть захвачены с помощью параметра SHOW MASTER STATUS / SHOW SLAVE STATUS на соответствующих узлах, хотя задержка репликации имеет точность только 1 секунду и только для каждого перехода. В наборе инструментов Percona есть сценарии для более точного определения задержек репликации.
Использование репликации с несколькими мастерами (например, вольфрам, Percona) избавляет от лишних хлопот, но требует дополнительных усилий / программного обеспечения для настройки.
Если сеть между NDOE выходит из строя, тогда все процессы могут работать нормально, но не смогут передавать данные - вам нужен мониторинг на каждом узле, чтобы проверить, может ли он связаться с вышестоящим узлом.
база данных MySQL Master, которая реплицируется на несколько подчиненных баз данных
Лучшей практикой было бы назначить одно из ведомых устройств также как ведущее - двунаправленная репликация. Таким образом, вы можете легко переключиться в случае сбоя или для выполнения задач обслуживания, таких как восстановление индексов, резервное копирование, изменение схемы.
В зависимости от количества подчиненных узлов вы также можете назначить узел разветвления распространять изменения.
Что касается управления эскалациями, планирования сценариев для сбора данных и т. Д., Существует множество доступных инструментов, которые делают это - я использую nagios, как и многие другие люди.
на рабе делать
SHOW SLAVE STATUS\G;
Если вы получаете это:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
это означает, что вы почти на месте, чтобы проверить его, попробуйте выполнить любые транзакции записи на MASTER и убедитесь, что они автоматически реплицируются на ведомом
Я искал инструменты для мониторинга, но не нашел ничего подходящего.
Вы можете использовать Шаблоны мониторинга Percona MySQL для Cacti. Ознакомьтесь с шаблоном репликации MySQL (который использует pt-heartbeat инструмент).
Ура