将mysqldump管道到mysql

par*_*err 9 mysql linux pipe mysqldump

有时我需要将MySQL数据库(db1)复制到另一个数据库(db2).我发现这个命令简洁有效:

mysqldump --opt db1 | mysql db2
Run Code Online (Sandbox Code Playgroud)

它工作正常,但现在它打破了以下错误:

错误1064(42000)在第1586行:您的SQL语法中有错误; 检查与MySQL服务器版本对应的手册,以便在'mysqldump'附近使用正确的语法:无法执行'SHOW TRIGGERS LIKE'seat_table_name'':第1行的MySQL服务器'

首先想到的是数据库太大(未压缩的SQL转储大于1G,目前为1090526011字节,确切地说),就像这样管道它.当我这样做mysqldump > file,然后mysql < file它工作正常,没有错误.错误消息(some_table_name)中提到的表不大或特殊.

第二个想法来自错误信息可能被截断的印象,并且它说

"...... MySQL服务器已经消失了"

对此的快速研究表明,有可能达到最大数量的打开文件(用于MySQL和/或系统).所以我尝试添加--skip-lock-tablemysqldump和提高open-files-limit,但没有运气,同样的错误.

明显的解决方案是进行转储然后导入(因为它工作正常),但管道似乎更好,更干净(让我知道,如果我错了),加上我很想知道导致这个问题的原因.我是否达到了影响命令管道的限制?

我一直在托管服务器上执行此操作,在Linux和我的开发机器上运行MySQL 5.1.60 - 在Linux上运行MySQL 5.1.58.后者给出了一个不同的错误:

mysqldump:错误2013:other_table_name在行转储表时查询期间丢失与MySQL服务器的连接:7197


更新:问题通过单独的转储和导入解决,没有管道.即使我觉得这不是我的问题的真正答案,但ssmusoke的建议最重要的是得到了接受的答案.

txy*_*oji 6

"MySQL服务器已经消失"是最大数据包错误的症状. http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

修改您的命令以为max_allowed_pa​​cket指定更大的值.

mysqldump --opt db1 | mysql --max_allowed_packet=32M db2
Run Code Online (Sandbox Code Playgroud)

默认值为1M.获得正确的价值可能需要反复试验. http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_pa​​cket


Ste*_*oke 4

问题可能是同时进行转储和加载,服务器上的负载变得太高。这也意味着您失去了一些优化,例如扩展插入、禁用外键的能力,这些优化可以在转储文件然后导入它时实现。

我建议您使用 mysqldump 生成备份,然后使用 mysql 加载它。这样,服务器上的负载就会减少,并且就像您所说的那样,它总是有效的。您甚至可以将其自动化到 bash 脚本中来执行这两项操作,这样您就不需要执行 mysqldump 和加载命令。