Piping mysqldump to mysql

Question

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

mysqldump --opt db1 | mysql db2 

Он работал отлично, но теперь он порывает с следующей ошибкой:

ERROR 1064 (42000) at line 1586: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'mysqldump: Couldn't execute 'SHOW TRIGGERS LIKE 'some_table_name'': MySQL server ' at line 1

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

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

"...MySQL server has gone away"

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

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

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

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table other_table_name at row: 7197

---

UPDATE: Проблема решается делать отдельный дамп и импорт, без трубы. Хотя я чувствую, что это не совсем ответ на мой вопрос, предложения ssmusoke были наиболее точными, что привело к принятому ответу.

Answer 1

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

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

Answer 2

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

mysqldump --opt db1 | mysql db2

Answer 3

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

Answer 4

«Сервер 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 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;

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