LINUX.ORG.RU
ФорумAdmin

mysqlbinlog и восстановление реплики

 , ,


0

2

Добрый день и заранее спасибо за ответы.

Ситуация такая:

Mysql Master - 1шт. Mysql Slave - 1шт. binlog mode - mixed

На днях датабейсер сделал массовый update в базе. При обновлении не был выставлен LIMIT 1000. И соответственно текущий logfile на мастере вырос до 18Гб. Естественно реплика его не смогла съесть, т.к. максимальный размер может быть 1024Мб.

Решил накатить вручную этот лог и предварительно сделал файл с данными для восстановления:

mysqlbinlog /data/mysql/mysql-bin.002678 > /home/db/db-db.sql Файл получился 25Гб.

Когда я изучил содержимое файла возникли вопросы на которые я пока не нашел ответ.

Начало лога, начало первой транзакции:

http://joxi.ru/Y2LKjLxFnZdVom

Потом идут много тысяч строк и commit конец транзакции:

http://joxi.ru/Q2KLndXS9KWGKA

Также в файле есть raw данные измененных строк.

В конце еще 300 других запросов в виде sql запросов и собственно конец файла лога.

Внимание привлекли контрольные суммы CRC32 измененных строк в первой транзакции. Они в комментариях, соответственно не будут обработаны при восстановлении: mysql dbname < file.sql. Да и вообще не выглядят как SQL запросы. Также raw данные

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

Решил поэкспериментировать и сделал с параметром -s

mysqlbinlog -s /data/mysql/mysql-bin.002678 > /home/db/db-db.sql чтобы убрать служебные строки из файла для восстановления.

Размер получился 67КБайт. Куда же делись данные первой транзакции и вообще 25Гб? Также raw данные не попали в файл.

Добавил параметры --base64-output=decode-rows -v и выполнил:

mysqlbinlog --base64-output=decode-rows -v /data/mysql/mysql-bin.002615 > /home/db/db-db.sql

Тут уже ситуация получше вышла, добавились закоментареные запросы на изменения строк, как я думаю строк которые были в формате raw. Также исчезли сами raw данные. Вывод diff: http://joxi.ru/MAjb0VkIvME1KA

C помощью sed я глобально убрал комментарии вида"### ". Потом накатил весь получившийся файл в базу. Делаю это первый раз - поэтому озадачен, все ли сделал правильно. Сам еще пока не очень глубоко разбираюсь в mysql.

Собственно вопросы:

1. CRC32 - это контрольная сумма для строк в формате raw?

2. Правильно я сделал восстановление из binlog?

3. Как вы делаете восстановление из binlog в формате mixed? Попадают ли у вас raw данные в базу?



Последнее исправление: iskinn (всего исправлений: 1)

Замудрил ты что-то.

Почему не подходит простой вариант снятия дампа мастера с текущей позицией бинлога и последующая заливка в слейв со стартом на указанной позиции?

Deleted
()
Ответ на: комментарий от WARNING

Потому что база 2.5Тб. Также есть удаленная реплика в другой стране для резервирование. И переделывать их это на 2-3 дня работы. А восстановление из binlog - это в течении 1 дня. Ну и если есть правильная последовательность восстановления из binlog, то почему бы ей не воспользоваться.

iskinn
() автор топика
Ответ на: комментарий от iskinn

Вопрос только в том, правильная она или нет.

Ну и это ещё одна причина, почему такие огромные базы это зло. Случись что, и сделать то с ней ничего не сможешь.

WARNING ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.