БЫСТРЫЙ дамп базы данных в режиме ожидания:
Использование опции "-T" с mysqldump приводит к большому количеству файлов .sql и .txt в указанном каталоге. Это на ~ 50% быстрее при выгрузке больших таблиц, чем в один файл .sql с операторами INSERT (занимает на 1/3 меньше времени настенных часов).
Кроме того, существует огромное преимущество при восстановлении, если вы можете загружать несколько таблиц параллельно и насыщать несколько ядер. На 8-ядерном корпусе это может быть как 8-кратная разница во времени настенных часов для восстановления дампа, в дополнение к улучшениям эффективности, обеспечиваемым "-T". Поскольку "-T" заставляет каждую таблицу храниться в отдельном файле, их параллельная загрузка проще, чем разделение массивного файла .sql.
Если довести приведенные выше стратегии до логического предела, можно создать скрипт для широкого параллельного выгрузки базы данных. Что ж, это именно то, чем являются инструменты Maakit mk-parallel-dump (см. http://www.maatkit.org/doc/mk-parallel-dump.html) и mk-parallel-restore; Perl-скрипты, которые выполняют несколько вызовов базовой программы mysqldump. Однако, когда я попытался использовать их, У меня были проблемы с выполнением восстановления без ошибок дубликатов ключей, которые не возникали с ванильными дампами, поэтому имейте в виду, что ваш пробег может отличаться.
Сброс данных из базы данных LIVE (без прерывания обслуживания):
Параметр --single -action очень полезен для создания дампа действующей базы данных без необходимости его остановки или создания дампа подчиненной базы данных без необходимости прекращения работы ведомой.
К сожалению, -T несовместим с --single -action, поэтому вы получаете только один.
Обычно получение дампа происходит гораздо быстрее, чем его восстановление. Еще есть место для инструмента, который берет входящий монолитный файл дампа и разбивает его на несколько частей для параллельной загрузки. Насколько мне известно, такого инструмента еще не существует.
Передача дампа по сети обычно является выигрышем
Чтобы прослушать входящий дамп на одном хосте, выполните:
nc -l 7878 > mysql-dump.sql
Затем на вашем хосте БД запустите
mysqldump $OPTS | nc myhost.mydomain.com 7878
Это уменьшает конкуренцию дисковых шпинделей на ведущем устройстве от записи дампа на диск, что немного ускоряет работу дампа (при условии, что сеть достаточно быстра для поддержания работоспособности, довольно безопасное предположение для двух хостов в одном центре данных). Кроме того, если вы создаете нового ведомого, это избавляет от необходимости передавать файл дампа после его завершения.
Предостережения - очевидно, вам необходимо иметь достаточную пропускную способность сети, чтобы не замедлять работу, и если сеанс TCP прерывается, вам нужно начинать все сначала, но для большинства дампов это не является серьезной проблемой.
Наконец, я хочу прояснить один момент общей путаницы.
Несмотря на то, как часто вы видите эти флаги в примерах и руководствах mysqldump, они излишни, потому что они включены по умолчанию:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
С http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html:
Использование --opt аналогично указанию --add-drop-table, --add-locks, --create-options, --disable-keys, --extended-insert, --lock-tables , --quick и --set-charset. Все опции, которые обозначают --opt, также включены по умолчанию, потому что --opt включен по умолчанию.
Из этих поведений "--quick" является одним из наиболее важных (пропускает кэширование всего набора результатов в mysqld перед передачей первой строки), и может быть с "mysql" (который НЕ включает --quick on по умолчанию) значительно ускорить запросы, которые возвращают большой набор результатов (например, вывод всех строк большой таблицы).