LINUX.ORG.RU
ФорумAdmin

Восстановление mysql-базы из поломанных бинарных логов

 , , ,


0

1

Здравствуйте, уважаемые эксперты.

Накрылся сервер mysql. Накрылся - закончилось место на диске из-за пухлых логов, indata и бинарных логов. Дамп есть от самого начала включения бинарных логов.

Задача - поднять все базы данных на новом сервере.

Centos 7, maria5.5

Логи сначала конвертировала в sql-файл командой

 mysqlbinlog -s -D --start-datetime="2016-12-13 17:29:00" --stop-datetime="2017-01-15 18:00:00" -t mysql-bin.000001 > repair20170115.sql
-t должно потянуть все остальные части логов. Не потянул, в итоге оставила команду
 mysqlbinlog -s -D mysql-bin.000001 > repair20170115-1.sql 
и все 13 частей перегнала. Загрузила дамп, выполнила sql-файлы из логов
 mysql -uroot -pPassword < repair20170115-1.sql
и так 13 раз. Ошибки появились на 9 части. Сайты, зависимые от этих баз, включились, но отказались распознавать админские пароли. Посмотрела в сами файлы-sql - там только фиксация времени и всё… При том что файл логов (стандартный, не аварийный) весит 100М, а sql-файл - порядка 8М, стало ясно, что он пустой)

Нашла такой вариант изъятия инфы:

 mysqlbinlog mysql-bin.000001 > 1.sql 
, сервер mysql всё равно отключен. Теперь изъятая из одного бинарного файла инфа весит ~195МБ. Это если файл «нормальный». Оказалось, что сервер три раза завершал работу аварийно и логи 6, 9 и 13 части неполные. Поставила новый сервер, применяю sql-файлы к загруженным базам. На 6 части -
 ERROR 1032 (HY000) at line 509660: Can't find record in 'job_queue'
В самом коде в строке 509660 ничего особенного, это первая треть файла.

Нашла разницу в заголовке и окончании «поломанного» файла: Так выглядит начало и окончание правильного sql-файл из бинарного лога.

 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#161213 19:03:56 server id 1  end_log_pos 245 	Start: binlog v 4, server v 5.5.50-MariaDB created 161213 19:03:56 
BINLOG '
...
'/*!*/;
# at 105413866
#161216  7:59:51 server id 1  end_log_pos 105413893 	Xid = 1144333
COMMIT/*!*/;
# at 105413893
#161216  7:59:51 server id 1  end_log_pos 105413936 	Rotate to mysql-bin.000004  pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

А так - поломанный, аварийно завершенный лог: (часть 6-ая, mysql-bin.000006)

 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#161220 23:36:50 server id 1  end_log_pos 245 	Start: binlog v 4, server v 5.5.50-MariaDB created 161220 23:36:50
# Warning: this binlog is either in use or was not closed properly. (Вот эта строка меня смутила)
BINLOG '
...(тут много-много записей, далее - окончание лога)
'/*!*/;
# at 48701294
#161222  5:26:33 server id 1  end_log_pos 48701321 	Xid = 3019671
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
Привела шестой sql-файл к виду
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#161220 23:36:50 server id 1  end_log_pos 245 	Start: binlog v 4, server v 5.5.50-MariaDB created 161220 23:36:50
BINLOG '
...
'/*!*/;
# at 48701294
#161222  5:26:33 server id 1  end_log_pos 48701321 	Xid = 3019671
COMMIT/*!*/;
# at 48701321
#161222  5:26:33 server id 1  end_log_pos 48701364 	Rotate to mysql-bin.000007  pos: 4  
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
Закинула всё это на новый сервер, распакованный по новой дамп. На шестой части - тоже самое:
ERROR 1032 (HY000) at line 509660: Can't find record in 'job_queue'
Какие видны варианты?

Нашла

Tits or Get The Frak Out.

anonymous
()
Ответ на: комментарий от goingUp

Не совсем.

Мариа не стартует. Место закончилось, я перенесла в сетевую директорию самый большой файл ibdata1=600M, без него mysql отказался запускаться. Вернула файл на место, права вернула mysql. Добавила место. Вариант восстановления innoDB изучала, после вашего вопроса применила. Нашла инструкцию http://blackbird.si/mysql-corrupted-innodb-tables-recovery-step-by-step-guide/

Добавила

innodb_force_recovery=2
innodb_purge_threads=0

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

А вот вторая 2name_db - повреждена. Около каждой прочеканной таблицы -

2name_db.tokens
Error    : Table '2name_db.tokens' doesn't exist
status   : Operation failed
Подключилась к этой базе через HeidiSQL - вообще база пустая.

Дамп с нее сделать не могу - пустая же.

 mysqldump -uroot -ppasswd 2name_db > 2name_db_crashed20170117.sql
mysqldump: Got error: 1146: "Table '2name_db.accounts' doesn't exist" when using LOCK TABLES

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

Провела

innodb_force_recovery=3
с пошаговым увеличением до 6.

В 2name_db так и остался 0кб.

т.е. ответ на ваш вопрос - совсем не получилось.

manik207
() автор топика
Ответ на: Не совсем. от manik207

Странно. Вы когда запускали mysql, то в /var/lib/mysql были все файлы, и ibdata* и iblog* и db_name/*, правильно?

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