☰

Тестирование репликации/синхронизации базы данных MySQL

tag-icon • tag-icon mysql replication mysql-replication database-administration
Тестирование репликации/синхронизации базы данных MySQL

Я настраиваю базу данных MySQL Master, которая реплицируется в несколько подчиненных баз данных.

Мой вопрос заключается в том, каковы наилучшие методы мониторинга и/или тестирования актуальности подчиненных баз данных, которые будут оповещать администратора в случае возникновения ошибки, приводящей к остановке репликации.

Я искал инструменты мониторинга, но не смог найти ничего подходящего.

Также, каковы подходы 'лучших практик' к тестированию синхронизации среди подчиненных. Есть ли что-то вроде Unit Testing для репликации БД?

Прошу прощения, если моя неосведомленность в этом вопросе кого-то обидела.

решение1

Большая проблема с репликацией — это проверка

  1. что все узлы подняты,
  2. все узлы взаимодействуют (не разделенный мозг)
  3. и обработка журналов репликации
  4. и задержка репликации

1, 3 и 4 можно захватить с помощью SHOW MASTER STATUS / SHOW SLAVE STATUS на соответствующих узлах, хотя задержка репликации имеет точность только в 1 секунду и только на каждом хопе. В наборе инструментов Percona есть скрипты для получения более точных задержек репликации.

Использование репликации с несколькими мастерами (например,вольфрам,Перкона) избавляет от многих проблем, но требует дополнительных усилий/программного обеспечения для настройки.

Если сеть между ndoes выйдет из строя, то все процессы могут работать нормально, но не смогут передавать данные. Вам необходимо провести мониторинг каждого узла, чтобы убедиться, что он может связаться с вышестоящим узлом.

База данных MySQL Master, которая реплицируется в несколько баз данных Slave

Лучше всего назначить одного из подчиненных серверов мастером — двунаправленная репликация. Таким образом, вы сможете легко переключаться в случае сбоя или для задач по обслуживанию, таких как перестроение индексов, резервное копирование, изменение схемы.

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

Что касается управления эскалациями, планирования сценариев для сбора данных и т. д., существует множество инструментов, которые это делают — я использую Nagios, как и многие другие люди.

решение2

Мой вопрос заключается в том, каковы наилучшие методы мониторинга и/или тестирования актуальности подчиненных баз данных?

Для простого тестирования вставьте/обновите данные на главном устройстве и убедитесь, что они реплицируются на подчиненные устройства.

Но для проверки согласованности,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,проверка_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сначала воспользоваться этой опцией.

решение3

на раба делать

SHOW SLAVE STATUS\G;

Если вы получаете это:

   Slave_IO_Running: Yes
  Slave_SQL_Running: Yes

это означает, что вы почти у цели, чтобы проверить это, попробуйте выполнить любые транзакции записи на ГЛАВНОМ сервере и убедиться, что они автоматически реплицируются на подчиненном сервере

решение4

Я искал инструменты мониторинга, но не смог найти ничего подходящего.

Вы можете использоватьШаблоны мониторинга Percona MySQL для Cacti. Ознакомьтесь с шаблоном репликации MySQL (который использует этот pt-heartbeatинструмент).

Ваше здоровье

Связанный контент