Назад | Перейти на главную страницу

mysqldump - where with = operator не получает все строки

У меня есть ситуация с конкретной таблицей, которая теперь думает, что она содержит 4 петабайта данных. Я знаю, это звучит круто, но уверяю вас, это только раздел на 60 ГБ.

В этой таблице 9 полей. Один из них - domain_id поле. Это лучшее поле для идентификации строк, поскольку их всего около 6300. Единственный другой вариант поля для сопоставления имеет более 2 миллионов записей, и это намного сложнее.

Я не могу сделать прямой mysqldump, потому что он попытается вывести все 4 ПБ данных и заполнить диск задолго до того, как он приблизится к этому, поэтому мне нужно хирургическим путем удалить хороший материал, уничтожить базу данных и воссоздать ее.

Я считаю, что если я смогу сделать дамп для каждого domain_id записи, то я получу из нее большую часть полезных данных. Вот что я пытаюсь использовать:

mysqldump -u root --skip-opt -q --no-create-info --skip-add-drop-table \
 --max_allowed_packet=1000000000 database table --where="domain_id=10" \
 > domains10.sql

Используя это, я ожидаю, что каждая строка с domain_id 10 на экспорт.

Однако, когда я проверяю экспорт, я получаю только 1 строку, но когда я смотрю на db, там много много строк. Это как если бы оператор просто нашел его, а затем отказался.

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

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

Также обратите внимание, что единственный способ получить эту БД, даже доступную, - это принудительное восстановление 3 innodb. Поэтому мне нужно сделать это правильно, потому что после этого мне нужно отбросить базу данных, чтобы снова сделать mysql работоспособным.

Будем рады любым полезным ответам.

Как вы думаете, насколько большим должен быть стол на самом деле?

Вы можете попробовать преобразовать его в myisam:

alter table ggg engine=myisam;

Однако похоже, что у вас повреждена база данных.

Лучший план - связаться с ребятами из innodb за поддержкой.

http://www.innodb.com/

Из того, что вы пишете, похоже, что база данных была повреждена (думать, что 4 ПБ вместо 60 ГБ - это своего рода раздача).

Я сомневаюсь, что вы можете получить какие-либо гарантии надежности полученной информации, если сначала не восстановите db. Вы пробовали это?

В противном случае, что произойдет, если вы нажмете клавишу «-f», чтобы продолжить, даже если возникнут ошибки?

Я не администратор базы данных, поэтому, возможно, эта идея совершенно неверна, но есть ли в дампе данные, которые должны быть согласованы во всех записях с текстовой строкой? Я подумал, можно ли сделать дамп базы данных размером "4 петабайта" и перенаправить его через фильтр grep / strings, чтобы, если поврежденные данные не являются допустимой строкой, они не будут записаны на диск. Это будет зависеть от того, были ли поврежденные данные просто непонятным мусором ...

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

Попробуйте добавить --skip-extended-insert. Возможно, что-то пошло не так при записи в файл.