Question

我正在尝试通过加载其中一个备份来构建生产MySQL数据库的开发副本。如果未压缩的转储是〜20G，需要多长时间才能完成？

这个命令已经运行了24h，CPU负载为10％，我想知道它是否只是很慢或者它/我做错了什么。

mysql -u root -p < it_mysql_dump.sql

顺便说一下，这是一台带有大量内存的强大桌面开发机器，但它可能正在读取和写入相同的硬盘驱动器。我想我正在使用InnoDB。

Answer 1

恢复MySQL转储可能需要很长时间。这是因为它确实重建了整个表。

你需要做什么来修复它取决于引擎，但一般来说

我想说，做以下事情：

Zeroth规则：仅使用64位操作系统。

确保你有足够的物理ram来将最大的单个表放入内存中;包括计算中操作系统的任何开销（注意：在使用4k页的操作系统，即所有这些页面表中，页表在大内存系统上占用大量内存 - 不要忘记这一点）
调整innodb_buffer_pool使其大于最大的单个表;或者如果使用MyISAM，请调整key_buffer，使其足以容纳最大表的索引。
请耐心等待。

现在，如果您仍然发现执行上述操作的速度很慢，则可能是您的特定数据库具有非常棘手的恢复结构。

就我个人而言，我已经设法用~2Tb重建服务器＆lt; 48小时，但这是一个特例。

如果您打算将生产数据加载到其中，请确保您的开发系统具有生产级硬件。

特别是，如果您认为可以将数据批量加载到不适合内存的表中（或者至少大部分加载到内存中），请忘掉它。

如果这一切看起来太多，请记住您可以使用InnoDB在线使用文件系统或LVM快照，然后只复制文件。使用MyISAM它有点棘手，但仍然可以完成。

Answer 2

打开另一个终端，运行mysql，并计算转储（SELECT COUNT(*) FROM table）中某些表中的行数。与源数据库比较。那会告诉你进展情况。

我在大约14个小时内通过网络将大约80GB的数据插入MySQL。它们是每行一次插入转储（慢速），有很多开销，插入带有快速磁盘的服务器上。

如果硬件足够老，或者您的导入与磁盘IO和内存的其他内容竞争，则可以24小时。

Answer 3

我刚刚完成了从36.8 Gb mysqldump文件恢复51.8 Gb数据库的经验，以创建一个imdb数据库。对我来说，没有通过网络完成但是从本机上的文件完成的恢复花了不到4小时。

该机器是运行Windows Server 2008的四核服务器。人们想知道是否有办法监控进度。实际上有。您可以通过转到Program Data目录并查找MYSQL子目录然后查找包含数据库名称的子目录来查看还原创建数据库文件。

文件逐渐构建在目录中，您可以观察它们的构建。如果您遇到生产问题，并且想知道还原作业是挂起还是只是花了很长时间，那就不小了。