MySQL中20GB的恢复需要多长时间？（又称：是否有问题？）

Question

MySQL中20GB的恢复需要多长时间？（又称：是否有问题？）

13

我正在尝试通过加载备份来构建一个生产MySQL数据库的开发副本。如果未压缩的dump文件大小约为20G，那么这个过程需要多长时间？

这个命令已经运行了大约24小时，CPU负载为10％左右，我想知道它是慢还是我（或者命令）做错了什么。

mysql -u root -p < it_mysql_dump.sql

顺便提一下，这是在一台配置不错的桌面开发机上进行的，内存充足，但可能会读写同一个硬盘。我认为我正在使用InnoDB。

- BCS

有多少RAM，硬盘的细节呢？IO是个问题。 - OMG Ponies

2

这是一台带有256MB内存的Pentium 2吗？ - DogDog

3个回答

5

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

我通过网络向MySQL插入了约80GB的数据，用了大约14个小时。它们是一次插入一行的转储（速度较慢），在一个具有快速磁盘的服务器上进行插入操作需要一定的开销。

如果硬件太老或者您的导入与其他东西竞争磁盘IO和内存，则可能需要24小时。

- Dan Grossman

我在其中一张表上执行了该操作（我认为正在加载的那张表），但查询已经几个小时没有返回，就好像该表被锁定无法读取。 - BCS

保存数据可能和从转储文件读取的数据竞争：）14小时对我来说是一个合理的范围。 - BCS

1

不幸的是，通常情况下您无法使用另一个会话监视还原操作，因为它们通常持有表锁。 - MarkR

3

您仍然可以查看新服务器上数据文件的大小来观察它们的增长。总有一种方法可以监视。 - Dan Grossman

4

我刚刚经历了从一个36.8 Gb的mysqldump文件中恢复一个51.8 Gb数据库的过程，以创建一个imdb数据库。对于我来说，这个恢复过程不是通过网络进行的，而是从本地机器上的一个文件进行的，花费了将近4个小时。这台机器是运行Windows Server 2008的四核服务器。人们一直想知道是否有一种方法来监控进度。实际上是有的。您可以通过前往Program Data目录并找到MYSQL子目录，然后找到您的数据库名称的子目录来观看恢复创建数据库文件的过程。在该目录中逐渐构建文件，并且您可以观察它们的构建过程。当您遇到生产问题并且想知道还是还是需要更长的时间时，这样做是不错的安慰。

- Elliott

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- MarkR · Accepted Answer

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

要解决问题，您需要根据引擎执行以下操作：

第0条规则：仅使用64位操作系统。

1.确保您有足够的物理内存来容纳最大的单个表；在此计算中包括操作系统的任何开销（请注意：在使用4k页面即所有操作系统的操作系统上，页表本身在大型内存系统上占用大量内存 - 不要忘记这一点）。

2.调整innodb_buffer_pool大小，使其大于最大的单个表；或者如果使用MyISAM，请调整key_buffer大小，以便它足以容纳最大表的索引。

3.耐心等待。

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

就我个人而言，我曾经成功地在不到48小时的时间内重新构建了一个约2Tb的服务器，但那是一个特殊情况。

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

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

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