将 mysqldump 管道传输到 mysql答案

【问题标题】：Piping mysqldump to mysql将 mysqldump 管道传输到 mysql
【发布时间】：2012-03-19 12:32:29
【问题描述】：

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

mysqldump --opt db1 | mysql db2

它工作正常，但现在它因以下错误而中断：

ERROR 1064 (42000) at line 1586: 你的 SQL 语法有错误；检查与您的 MySQL 服务器版本相对应的手册在'mysqldump：无法执行'SHOW TRIGGERS附近使用正确的语法 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，但没有运气，同样的错误。

明显的解决方案是转储然后导入（因为它工作正常），但管道对我来说似乎更好更干净（如果我错了，请告诉我），而且我很想知道是什么原因造成的问题。我是否达到了影响命令管道的某些限制？

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

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

更新：通过单独转储和导入解决问题，无需管道。尽管我觉得它并不能真正回答我的问题，但 ssmusoke 的建议最中肯，最终得到了接受的答案。

【问题讨论】：

标签： mysql linux pipe mysqldump

【解决方案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

【讨论】：

【解决方案2】：

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

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

【讨论】：

我怀疑负载是否高到连接断开。即使是这样，我也会很奇怪它总是在同一个地方（同一张桌子）失败，对吧？无论如何，这个过程是脚本化的，但是当它开始失败时，我不得不把它拿出来并开始“手动”分析，现在它（我希望暂时）正在处理文件。不过，我想知道它以这种方式失败的原因是什么。感谢您的建议。

【解决方案3】：

您是否需要重定向 stderr 流以及来自 mysqldump 的 stdout？错误消息可能与转储输出交错。试试

mysqldump --opt db1 | mysql db2

【讨论】：

我真的不知道，但这是剩下的，没有它正在测试，抱歉误导你，我会编辑问题。

【解决方案4】：

问题是您将stderr 重定向到stdout，因此任何错误都被解释为SQL。删除 2>&1。那么真正的错误就会出现。

【讨论】：

实际上，重定向是剩余的，我在没有它的情况下进行测试，对不起。无论哪种方式，当我将转储重定向到文件时，它都没有错误，管道也应该如此，对吧？
我假设这两个数据库在同一台服务器上。在源数据库上，mysqldump 会锁定表以生成比平时消耗更多资源的查询。在目标数据库上执行每条 SQL 语句——更新索引、创建日志等，这也消耗了大量资源。另一方面，sql 脚本包含一些优化，例如不检查插入的每一行的外键约束、批量的扩展插入

【解决方案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;

^ 你可能需要超级权限

【讨论】：