Трубопровод mysqldump к mysql

Question

Иногда мне нужно скопировать базу данных MySQL (db1) в другую базу данных (db2). Я нашел эту команду краткой и эффективной:

mysqldump --opt db1 | mysql db2

Работало нормально, но теперь ломается со следующей ошибкой:

ОШИБКА 1064 (42000) в строке 1586: у вас ошибка в синтаксисе SQL; проверьте руководство, которое соответствует вашей версии сервера MySQL для правильный синтаксис для использования рядом с «mysqldump: не удалось выполнить» ПОКАЗАТЬ ТРИГГЕРЫ LIKE 'some_table_name' ': MySQL server' в строке 1

Первое, что приходит на ум, это то, что база данных слишком велика (несжатый дамп SQL в настоящий момент> 1G, если быть точным, 1090526011 байт) для такой передачи по конвейеру. Когда я делаю mysqldump > file, а затем mysql < file, он работает нормально, без ошибок. Таблица, упомянутая в сообщении об ошибке (some_table_name), не является большой или специальной.

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

"... сервер MySQL ушел"

Быстрое исследование говорит о том, что возможно достижение максимального количества открытых файлов (для MySQL и / или системы). Поэтому я попытался добавить --skip-lock-table к mysqldump и поднять open-files-limit, но не повезло, та же ошибка.

Очевидное решение - сделать дамп и затем импортировать (как это работает нормально), но мне кажется, что трубопроводы лучше и чище (дайте мне знать, если я ошибаюсь), плюс мне любопытно выяснить, что вызывает проблема. Я достиг определенного предела, который влияет на командный конвейер?

Я делал это на хостинг-сервере, на MySQL 5.1.60 работал под Linux, а на моей машине для разработки - MySQL 5.1.58 на Linux. Последнее дает немного иную ошибку:

mysqldump: Ошибка 2013: Потеря соединения с сервером MySQL во время запроса при сбросе таблицы other_table_name в строке: 7197

---

ОБНОВЛЕНИЕ: Проблема решается с помощью отдельного дампа и импорта без конвейера. Несмотря на то, что я чувствую, что это не совсем ответ на мой вопрос, предложения ssmusoke были наиболее точными, что привело к принятию ответа.

Answer 1

«Сервер MySQL ушел» является признаком ошибки максимального пакета.http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

Измените команду, указав большее значение для max_allowed_packet.

mysqldump --opt db1 | mysql --max_allowed_packet=32M db2

По умолчанию установлено значение 1M.Это может занять проб и ошибок, чтобы получить правильное значение.http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet

Answer 2

Проблема может заключаться в том, что нагрузка на серверы становится слишком высокой при одновременном выполнении дампа и загрузки.Это также означает, что вы теряете некоторые оптимизации, такие как расширенные вставки, возможность отключить внешние ключи, которые могут быть достигнуты при выгрузке файла и его импорте.

Я бы порекомендовал использовать mysqldump для создания резервной копии и затем загрузить ееиспользуя mysql.Таким образом снижается нагрузка на ваш сервер, и, как вы сказали, это всегда работает.Вы даже можете автоматизировать его в сценарии bash, чтобы выполнить оба действия, чтобы вам не нужно было выполнять команды mysqldump и loading.

Answer 3

Проблема в том, что вы перенаправляете stderr в stdout, поэтому любые ошибки интерпретируются как SQL.Удалить 2> & 1.Тогда появится настоящая ошибка.

Answer 4

Вам нужно перенаправить поток stderr, а также стандартный вывод из mysqldump?Сообщения об ошибках могут чередоваться с выводом дампа.Попробуйте

mysqldump --opt db1 |mysql db2

Answer 5

возможно, что резервное копирование выходит за пределы тайм-аута MySQL.

Переменные можно изменить в my.cnf

net_read_timeout = 120 net_write_timeout = 900

Если вы предпочитаетеизмените эти настройки без перезагрузки MySQL, вы можете сделать это с помощью следующих операторов SQL:

set global net_read_timeout = 120; set global net_write_timeout = 900;

^ вам может потребоваться супер привилегия