Проверка идентичности MySQL Slave сервера
СУБД MySQL, самая популярная СУБД для WEB проектов. Эту БД используют миллионы проектов по всей сети Интернет, от крупных компаний, до отдельных разработчиков, и как следствие, перед любым администратором СУБД MySQL рано или поздно встает вопрос об обеспечении отказоустойчивого режима работы данной подсистемы БД в рамках проекта. СУБД MySQL (далее просто MySQL или СУБД) предлагает 2-а механизма высокодоступного режима работы:
Оба механизма имеют свои плюсы и минусы, но всетаки более популярен и доступен — это 2-ой вариант, то есть репликация данных между MySQL серверами. Настройка репликации отлично описана в документации, поэтому рассматривать мы ее не будем. Предмет данной заметки — проверка MySQL slave сервера на идентичность его данных MySQL master серверу.
Не все администраторы это знают, но из-за того, что репликация в MySQL 4.1-5.0 производится при помощи бинарных логов, в которые пишутся SQL запросы, которые в последствии выполняются MySQL slave сервером, данные на slave сервере могут отличаться от данных на master сервере, причем, как показывает практика, такие ситуацию случаются регулярно.
Соответственно, задача любого MySQL администратора — это обеспечить ежедневную проверку идентичности данных slave сервера с последующей синхронизацией данных, в случае необходимости.
Для проверки идентичности данных я использую утилиту mk-table-checksum из пакета Maatkit. Данная утилита умеет проверят идентичность данных между серверами, выборочно по базам данных или отдельным таблицам, с помощью разных алгоритмов (ACCUM, BIT_XOR, CHECKSUM), причем, как между серверами связанными репликацией, так и нет. Суть работы данной утилиты — конкатенация всех данных в таблице, с дальнейшим получением контрольного числа для данного объема данных. Для проверки я использую следующие параметры для запуска данной утилиты:
mk-table-checksum --quiet --algorithm BIT_XOR --chunk-size 500000 --nocrc --empty-replicate-table --float-precision 5 \
--function FNV_64 --optimize-xor --replicate=test.checksum --sleep-coef=0.5 --socket /tmp/mysql_socket_path.sock \
h=MYSQL_HOST,P=MYSQL_PORT,u=MYSQL_USER,p=MYSQL_PASS,A=cp1251Ключевые параметры:
—algorithm BIT_XOR — алгоритм BIT_XOR, для получения финальной контрольного числа, данный алгоритм не учитывает очередность вставки данных в таблице, соответственно если на slave сервере данные находятся в другом порядке, чем на master сервере, то данный алгоритм не позволит это обнаружить, при такой ситуации нужно использовать алгоритм ACCUM.
—function FNV_64 — хеш функция для обработки контрольного числа полученного при помощи алгоритам BIT_XOR или ACCUM. Я использую функцию FNV_64, данная функция доступа после установки UDF модуля, исходный код данного модуля распространяется вместе с Maatkit.
Для проверки должен быть указан адрес MySQL master сервера, после запуска утилиты определяются БД для проверки и выполняются SQL запросы вида REPLACE с записью конечных данных в таблицу test.checksum, далее эти SQL запросы при помощи репликации передаются на slave сервер, где также выполняются. Соотвественно если результат выполнения одинх и техже запросов равен на master и slave сервере, значит считаем, что данные на серверах идентичны.
Далее для проверки и синхронизации данных, если это требуется, используем утилиту mk-table-sync. Я использую следующие параметры для запуска:
mk-table-sync --print --verbose --function FNV_64 --replicate test.checksum --sync-to-master \
h=MYSQL_HOST,P=MYSQL_PORT,u=MYSQL_USER,p=MYSQL_PASS,A=cp1251
Ключевые параметры:
—print — вывести информацию, если найдены различия, изменение данных не производится.
—sync-to-master — все изменения, если найдены различия, будут проводиться на MySQL master сервере. Это особенно актуально в случае master-master репликации. В случае если вместо параметра —print будет параметр —execute, данная утилита определит какие данные между master и slave сервером различаются, подключится к master серверу и выполнит необходимые запросы (REPLACE, DELETE) для приведения slave сервера в идентичное состояние master серверу.
Также часто приходится пользоваться параметром —noforeign-key-checks, для отключения проверки foreign-key`s. Их выполнение все равно не нужно, если данные в итоге будут идентичны на обоих серверах.
Проводя такую нехитрую проверку каждый день, мы можем гарантировать, что данные между master и slave серверами идентичны, и в случае отказа master сервера MySQL администратор сможет без проблем задейстовать slave сервер для обеспечения дальнейшей работы WEB проекта.
В следующей заметке опишу способ простой автоматизации проверки идентичности MySQL master и slave серверов с последующей нотификацией, в случае проблем, при помощи системы мониторинга Nagios.
