Надежные резервные копии для огромных баз данных MySQL?

У меня есть база данных mysql/innodb объемом 200 ГБ / 400Mrows - намного больше, чем разумно, как я выяснил.

Одна удивительная проблема — восстановление резервных копий. mysqldump создает огромные файлы sql, и им требуется около недели, чтобы импортировать их обратно в новую базу данных (попытки ускорить его, такие как большие/меньшие транзакции, отключение ключей во время импорта и т. д., сжатие сети и т. д. пока не увенчались успехом, импорт myisam кажется в 2 раза быстрее, но тогда не было бы транзакций).

Что еще хуже - и я надеюсь получить некоторую помощь в этом - сетевое соединение, которое передает> 200 ГБ в течение недели, имеет нетривиальную вероятность разрыва, и процесс импорта sql не может быть продолжен каким-либо нетривиальным способом.

Что было бы лучшим способом справиться с этим? Прямо сейчас, если я замечаю разорванное соединение, я вручную пытаюсь выяснить, когда оно закончилось, проверяя самый высокий первичный ключ последней импортированной таблицы, а затем использую perlscript, который в основном делает это:

perl -nle 'BEGIN{open F, "prelude.txt"; @a=<F>; print @a; close F;}; print if $x; $x++ if /INSERT.*last-table-name.*highest-primary-key/'

Это действительно не выход, так что было бы лучше всего?


mysql database-restore
person taw    schedule 29.01.2010    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Достаточно ли места на жестком диске вашего сервера MySQL для удвоения всех данных? Здесь лучше всего подойдет локальное хранилище, но если это не вариант, вы также можете попробовать какое-нибудь устройство NAS, использующее iSCSI. Это все еще происходит по сети, но в этом случае вы получаете большую пропускную способность и надежность, потому что вы полагаетесь только на NAS с довольно тонкой ОС, который почти никогда не нужно перезагружать.

person Scott Anderson    schedule 29.01.2010
comment
Все это в облаке Amazon. До сих пор не было сбоев, но я не чувствую себя ужасно счастливым из-за того факта, что если он когда-либо произойдет, потребуется не менее недели, чтобы восстановить резервные копии + случайные специальные сценарии perl, если он по какой-либо причине выйдет из строя на полпути. - person taw; 29.01.2010

arrow_upward
1
arrow_downward

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

Лучше всего сделать снимок тома каталога базы данных и каким-то образом заархивировать его — что мы обычно и делаем — или выполнить rsync в другом месте.

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

Чтобы восстановить его, просто сделайте наоборот, затем перезапустите и подождите (возможно, некоторое время), пока восстановление innodb не исправит ситуацию.

Инструменты maatkit mk-parallel-dump и restore немного лучше, чем mysqldump, с точки зрения скорости, но я не уверен на 100% в их правильности

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

person MarkR    schedule 30.01.2010
comment
важное замечание по этому поводу: убедитесь, что вы сделали резервную копию файлов ibdata (ibdata1 и т. д.) в каталоге данных mysql. Это используется innodb, и без него резервные копии будут неправильными. - person Oliver M Grech; 06.05.2017

arrow_upward
0
arrow_downward

Вам нужно все, что есть в базе?

Можете ли вы передать часть информации в базу данных архива и добавить что-то в свое приложение, что позволит людям просматривать записи в архиве,

Очевидно, что это во многом зависит от вашего приложения и настройки, но это может быть решением? Ваша БД, вероятно, будет только увеличиваться....

person Matt    schedule 29.01.2010
comment
В долгосрочной перспективе это необходимо будет исправить, но сейчас я просто пытаюсь, чтобы все это работало должным образом. - person taw; 29.01.2010