Версия для печати
24
Мар
2008

MySQL binlog trimmer

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

Погуглив, нашел пару таких скриптов, но: один был очень сложный и совмещенный с бэкапом этих логов, а второй просто удалял все логи старше 15 дней. Меня это не устраивает – потому как хочется быть уверенным, что удаляемые логи уже точно вкатались в slave-сервер. При соблюдении этого условия мне нет необходимости их бэкапить.

Потому написал такой перловый скрипт: mysql_binlog_trimmer.pl

Работает этот скрипт так:

читаем список групп слейв серверов, и по очереди от каждого слейва в группе получаем соответствующее имя мастер-сервера и текущий бинарный лог на слейве. Сравниваем их между слейвами в одной группе. Если они везде одинаковы, то следуем далее. Получаем имя бинарного лога с соответствующего мастера и сравниваем имена логов мастера и слейва. Если имена совпадают – то все старые логи можно удалить. И на мастере вызывается комманда: PURGE MASTER LOGS TO <binlog.name>

Если скрипт запустить без параметра, то он работает в режиме только чтения. Он получает имена логов, сравнивает, показывает результат, но не выполняет PURGE

Что бы скрипт выполнил то, что требуется, его надо запустить с параметром --do:

./mysql_binlog_trimmer.pl --do

Более подробно словами работу этого скрипта можно описать так:

PURGE MASTER LOGS TO 'logname' выполняется на мастер-сервере.

Удаляет все журналы репликации, которые перечислены в индексном файле журналов до передаваемого журнала, и удаляет их из индексного файла журналов. Таким образом передаваемый журнал становится первым в индексном файле журналов.

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

Сначала необходимо проверить все подчиненные серверы при помощи команды SHOW SLAVE STATUS, чтобы увидеть, какой журнал используется, затем при помощи команды SHOW MASTER STATUS на головном сервере, найти тот журнал, который в данный момент заполняет мастер. Если везде это один и тот же журнал (т.е. все подчиненные серверы получили последние обновления), сделать резервные копии всех журналов, которые должны быть удалены (необязательно), и очистить все до целевого журнала.

UPD: В данный момент мы не можем получить список ВСЕХ подчинённих серверов. Потому скрипт построен так, что ему указывают имена подчиненных серверов и от них мы узнаем имя мастера. Но у мастера мы не можем получить список остальных подчиненных серверов (если таковые есть). Потому скрипту необходимо сообщать группу подчиненных серверов для одного мастера.

Можно попробовать использовать комманду SHOW SLAVE HOSTS, что бы получать этот список, но есть одно НО: такой список будет содержать только те подчиненные сервера, которые запущены с опцией: (--report-host=slave_name) Что не всегда у нах выполняется.


По теме:

Комментарии (2) на запись “MySQL binlog trimmer”

  1. снеговичпок пишет:

    перевыложите, пожалуйста, скрипт.

    спасибо

  2. kocmuk.ru пишет:

    Ой! Да, спасибо. Поправил ссылку.

Оставить комментарий


Антиспам-картинка