PDA

Просмотр полной версии : mysql, востановление большого бекапа


che
04.10.2010, 23:00
трабла, есть бекап ~6G

mysql -u root -p -f databasename < ./base_6G.sql

при выполнении виснет на прочь :(, есть какие нибудь хитрые настройки mysql?

nobody
04.10.2010, 23:22
если именно средствами мускула то плохо, max_allowed_packet надо поставить >6 Гб, даже не знаю реально ли это
по этому советую просто разбить дамп, и импортировать по кускам, подобные автомат-решения видел только на пхп (sypex dumper)

che
04.10.2010, 23:47
пхп обломается система 32 битная :(
чё делать блин?

oRb
05.10.2010, 00:08
при выполнении виснет на прочь
ну дык 6ти гиговый дамп мускул будет оооооооооочень долго импортировать) Просто так он не отвалится. Уберите ключ -f, возможно "mysql has gone away" не отображается. Если отвалиться на этом, тогда увеличиваете max_allowed_packet, но не на 6 гигов, конечно. И советую воспользоваться утилитой pv, чтобы наглядно видеть, какой объем данных был обработан и сколько осталось.

nobody
05.10.2010, 00:11
да не, разрядность тут не при чём, сайпекс разбивает файлы. Элементарно проверено, upload_max_size в php.ini гораздо меньше чем весит файл, но дамп корректно импортируется

p.s. насчёт pv хорошо подмечено, но в любом случае еще смотри в ps ax за статусом процесса

nikp
05.10.2010, 08:47
С большими файлами, в некоторых случаях, хорошо работала утилита bigdump.php (http://www.ozerov.de/bigdump.php), загружал ей до 1,5G.

Патч на ограничение PHP на 2G (http://news.php.net/php.internals/32767)

Если есть ограничение на 2Гб/4Гб лимит файловой системы, таблицы создавать с опцией RAID_TYPE.

По умолчанию MySQL таблицы имеют максимальный размер 4G (вроде бы), для обхода ограничения, создавать таблицу нужно c опциями AVG_ROW_LENGTH и MAX_ROWS.

hack4life
25.06.2011, 00:03
локально можно использовать source

mysql SOURCE /www/vhosts/examplesite.com/db.sql

chupakabra
09.12.2011, 05:07
Был дамп, представляющий собою одну команду INSERT с перечислением значений полей на 20+ Гб, висло при любых значениях max_allowed_packet и в любом софте (Sypex тоже обламывался).
Вопрос решился разбиением одного большого INSERT-а на 100500 одиночных INSERT-ов, обрабатывался и импортитовался дамп долго, но зато сработало.

yesday
16.12.2011, 04:01
Автор, попробуй так:
cat ./base_6G.sql | pv | mysql -u root -p databasename
Импортироваться и правда долго будет, так что терпение.

oRb
16.12.2011, 11:42
yesday, начнем с того, что прошло уже больше года с возникновения вопроса. Вряд ли вопрос все еще актуален.
И зачем городить огород из катов и пв?

SynQ
16.12.2011, 13:01
Я бы не отказался от рабочего скрипта, который Вопрос решился разбиением одного большого INSERT-а на 100500 одиночных INSERT-ов,
в зависимости от выставленного лимита на память: ставишь 5 мб, он делает extended-insert размером не более 5 мб. И отдельной опцией "полностью избавить от extended-insert".

yesday
16.12.2011, 13:40
yesday, начнем с того, что прошло уже больше года с возникновения вопроса. Вряд ли вопрос все еще актуален.
И зачем городить огород из катов и пв?
Тьфу, слепой :) На дату не обратил внимания. Ну, может кому пригодится.
А по поводу катов и пв - с такими объёмами я предпочитаю всё таки быть в курсе, на какой стадии находится процесс восстановления.
Можно конечно трекать позицию файла через /proc/$pid/fdinfo/$fd - но вот это как раз огород.
cat и pv просто повышают информативность происходящего.

oRb
16.12.2011, 15:06
я имел имел в виду другое.
Usage: pv [OPTION] [FILE]...
Зачем юзать кат, когда pv сам спокойно читает файлы.

yesday
18.12.2011, 14:58
Разницы по большому счёту нет (даже кол-во системных вызовов не меняется :) ).
Как по мне - так читабельней просто.

В том то и прелесть *nix - одну и ту же задачу можно выполнить по-разному (правда это часто служит поводом для холивара).