2010-11-28 4 views
2

У меня есть большая база данных MySQL 5 для сайта drupal на старой машине. После того, как резервное копирование и восстановление на новой базе данных, я получил:Как проверить целостность MySQL?

ERROR 1064 (42000) в строке * *: Вы есть ошибка в вашем SQL синтаксиса; проверьте руководство, соответствующее , версию вашего сервера MySQL для правильного синтаксиса , который используется рядом с '' captcha_success_form_ids | a: 1: {s: 13: \ "user_register \"; s: 13: \ "user_register \"; } зр» в строке 1

Я не уверен, какая таблица является Origion этой ошибки (я не имею таблицу под названием„user_register“). Поэтому мне интересно, как я могу быстро проверить исходную базу данных на предмет целостности, прежде чем делать еще одну неудачную попытку резервного копирования/восстановления? (У меня есть доступ к командной строке). Благодаря

+0

его не таблица user_register, ее данные, которые вы пытаетесь вставить, кажется, что вы сериализуете, и попробуйте вставить это – 2010-11-28 06:42:09

+0

. Как вы создаете резервную копию? Например, вы используете mysqldump, администратор MySQL и т. Д.? Попробуйте использовать mysqldump и убедитесь, что вы получаете ту же ошибку. – cbranch 2010-11-28 06:44:15

ответ

2

фрагмент цитируется в сообщении об ошибке не выглядит как MySQL - это выглядит как сериализованный PHP данные, что делает меня думать, что вы не избежать данных должным образом в код. Изменена ли ваша установка PHP? В частности, смартфонов? (примечание smartquotes теперь устарело).

3

Если вы подозреваете коррупцию в исходной базе данных, вы можете сделать следующее:

Для MyISAM таблиц:

CHECK TABLE <table_name>; 
REPAIR TABLE <table_name>; 

Для таблиц InnoDB:

http://www.mysqlperformanceblog.com/2008/07/04/recovering-innodb-table-corruption/

Я лично видел коррупцию с таблицами MyISAM в нескольких редких случаях, которые CHECK и REPAIR смогли обнаружить и исправить. Я никогда не сталкивался с коррупцией с таблицами InnoDB, поэтому не могу говорить из личного опыта относительно информации, предоставленной в ссылке.

Если бы я был на вашем месте, я бы начал с более детального изучения выходного файла, созданного mysqldump, чтобы узнать, могу ли я определить источник ошибки. mysqldump обычно выводит один оператор INSERT для каждой таблицы со всеми данными в одной строке, поэтому немного сложно диагностировать ошибки, потому что номер строки, включенный в сообщение об ошибке, не очень помогает. Итак, я бы сделал, чтобы отредактировать выходной файл mysqldump и вставить строки новой строки между каждой строкой. Например:

Оригинал:

INSERT INTO table VALUES (a,b,c),(d,e,f),(g,h,i), ... 

Изменение To:

INSERT INTO table VALUES (a,b,c), 
(d,e,f), 
(g,h,i), 
... 

Поскольку вы комфортно с командной строки, вы, вероятно, автоматизировать с СЭД и т.д.

Затем попробуйте импортировать измененный файл. Вы должны получить ту же ошибку, но на этот раз номер строки поможет определить точную строку, вызывающую проблему. В этот момент вы должны иметь возможность диагностировать проблему (или размещать здесь оскорбительную часть вывода mysqldump, и мы постараемся помочь).

EDIT:

ли сообщение об ошибке, что вы цитировали происходит, когда вы импорт базы данных? Или успешно импортируется база данных, но приложение вызывает сообщение об ошибке при доступе к базе данных? Я принимал первое, но теперь думаю, что это может быть последнее после повторного чтения вашего вопроса.

Еще одна идея: содержит ли ваша база данных хранимые процедуры? Если это так, mysqldump не будет включать их по умолчанию. Вам нужно, чтобы использовать --routines варианта:

mysqldump --routines -u <user> -p<password> <database> > output 
Смежные вопросы