MariaDB需要使用年龄来恢复备份

Question

因此，我做了一个相当大的db的mysqldump，现在我尝试使用以下方法来恢复它：

mysql db_test < db_test.sql

但看上去不会在今年年底结束。现在已经一个小时了，而且还在“恢复”。做后援花了大约10分钟，所以恐怕有什么不好的事情发生了。

到目前为止：

• 我已经检查过mysqld正在消耗我的cpu (有时高达80% )。
• 日志里没有和它相关的东西。
• 我可以看到创建并填充了大量表(不是所有表)的数据库。此外，在执行use db_test;时，我会收到以下消息:读取表信息以完成表名和列名--您可以关闭此功能，以便更快地使用-A启动
• 原始db文件在25 db左右，整个小时后，df -h返回与以前相同的空闲空间。所以我想它不会在磁盘上做任何事情。

奇怪的是，在检查top__时，我发现kworker有时消耗了100%的cpu，这不应该发生。

我能做些什么来看看发生了什么吗？

Answer 1

听起来，底层磁盘很忙。恢复大型数据库的问题是，每个插入(组)都需要一个刷新/同步操作，这在机械磁盘上非常慢( 7200 RPM磁盘的大小约为100 IOPS)。

为了加速恢复，您必须临时指示MySQL/MariaDB不要发出刷新/同步。为此，请用以下两行中断还原并编辑/etc/my.ini：

• innodb_flush_method=nosync
• innodb_flush_log_at_trx_commit=2

然后重新启动MariaDB并重新尝试恢复。现在事情应该进展得快得多。

还原之后，删除上面的行，否则您的数据库将有一个短而坏的寿命:刷新/同步存在是出于非常重要的原因。虽然关闭它们以进行还原是可以接受的，但是生产数据库不应该没有它们而运行。

Answer 2

如果您的底层存储是普通的旧磁盘，对于25 dbs的磁盘上MySQL数据库来说，这是非常正常的经历--长达几个小时的恢复--特别是对于一些结构糟糕的dbs(大量元组、索引等)。

要开始压缩转储，可以节省大量的I/O，并减少缓存内存的压力：

mysqldump foo |gzip >foo.sql.gz
zcat foo.sql.gz |mysql foo

在您的例子中，因为您已经完成了mysqldump：

gzip db_test.sql
zcat db_test.sql.gz |mysql db_test

除了您的系统性能(存储、内存等)外，MySQL设置可能会产生巨大影响。但这是一个完整的专业知识，没有什么可以通过一个ServerFault问题来处理.