SysAdmins Location

СУБД MySQL, самая популярная СУБД для WEB проектов. Эту БД используют миллионы проектов по всей сети Интернет, от крупных компаний, до отдельных разработчиков, и как следствие, перед любым администратором СУБД MySQL рано или поздно встает вопрос об обеспечении отказоустойчивого режима работы данной подсистемы БД в рамках проекта. СУБД MySQL (далее просто MySQL или СУБД) предлагает 2-а механизма высокодоступного режима работы:

1) MySQL Cluster

2) MySQL Replication

Оба механизма имеют свои плюсы и минусы, но все таки более популярен и доступен – это 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), причем, как между серверами связанными репликацией, так и нет. Суть работы данной утилиты – конкатенация всех данных в таблице, с дальнейшим получением контрольного числа для данного объема данных. Для проверки я использую следующие параметры для запуска данной утилиты:

[codesyntax lang=”bash”]

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

[/codesyntax]

Ключевые параметры:

–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. Я использую следующие параметры для запуска:

[codesyntax lang=”bash”]

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

[/codesyntax]

Ключевые параметры:

–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.