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