У меня есть ситуация с конкретной таблицей, которая теперь думает, что содержит 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 строку, когда же я смотрю на базу данных, там много-много строк. Как будто оператор просто находит одну, а затем сдается.
Я пробовал разные операторы. Используя <или >мне удается получить больше данных, но экспорт останавливается на определенных строках, где данные были скомпрометированы. При более чем 6000 для обработки я не могу достаточно легко сузить круг строк, затронутых экспортом.
Итак, мне нужен оператор, который по сути будет делать то, что я и предполагал =, а именно просто экспортировать все записи, соответствующие определенному полю.
Также обратите внимание, что единственный способ, которым я вообще получил доступ к этой базе данных, — это принудительное восстановление innodb 3. Поэтому мне нужно сделать это правильно, потому что после этого мне придется удалить базу данных, чтобы снова сделать MySQL работоспособным.
С нетерпением жду любых полезных ответов.
решение1
Из того, что вы пишете, следует, что база данных была повреждена (думаю, что 4 ПБ вместо 60 ГБ — это своего рода выдача).
Сомневаюсь, что вы можете получить какие-либо гарантии надежности полученной информации, если только вы сначала не восстановите базу данных. Вы пробовали это?
В противном случае, что произойдет, если вы нажмете клавишу «-f» — чтобы продолжить работу даже при возникновении ошибок?
решение2
Как вы думаете, насколько большим должен быть стол?
Вы можете попробовать преобразовать его в myisam:
alter table ggg engine=myisam;
Однако, похоже, у вас повреждена база данных.
Лучшим планом будет обратиться за поддержкой к ребятам из innodb.
решение3
Я не администратор базы данных, так что, возможно, эта идея совершенно ошибочна, но есть ли в дампе данные, которые должны быть согласованы во всех записях с текстовой строкой? Мне интересно, возможно ли сделать дамп вашей "4 петабайтной" базы данных и перенаправить ее через фильтр grep/strings, чтобы, если поврежденные данные не являются допустимой строкой, они не записывались на диск. Это будет зависеть от того, были ли поврежденные данные просто непонятным мусором...
В противном случае кому-то другому придется предложить инструмент для исправления базы данных.
решение4
Попробуйте добавить --skip-extended-insert. Возможно, что-то искажается при записи в файл.