☰

MariaDB 需要很长时间才能恢复备份

tag-icon • tag-icon mysql backup database mariadb
MariaDB 需要很长时间才能恢复备份

因此，我mysqldump对一个非常大的数据库进行了操作，现在我正尝试使用以下命令恢复它：

mysql db_test < db_test.sql

但看起来今年年底前不会结束。现在已经过去大约一个小时了，仍然在“恢复”。备份花了大约 10 分钟，所以我担心发生了什么不好的事情。

迄今为止：

  • 我已经检查过它mysqld正在消耗我的 CPU（有时高达 80％）。
  • 日志中没有与此相关的内容。

  • 我可以看到数据库已创建并填充了大量表格（但不是全部）。此外，当我执行时use db_test;，我收到以下消息：

    读取表信息以完成表和列名您可以关闭此功能以使用 -A 更快地启动

  • 原始数据库文件大约 25GB，经过一小时后，df -h返回的可用空间与之前相同。所以我猜它没有在磁盘上执行任何操作。

奇怪的是，当我检查时top，我发现它kworker有时会消耗高达 100% 的 CPU，这是不应该发生的

有什么想法或我可以做些什么来了解发生了什么事？

答案1

听起来好像底层磁盘很忙。恢复大型数据库的问题是每个（组）INSERT 都需要刷新/同步操作，这在机械磁盘上​​非常慢（7200 RPM 磁盘的速度约为 ~100 IOPS）。

为了加快恢复速度，您必须暂时指示 MySQL/MariaDB不是发出刷新/同步。要做到这一点，请中断恢复并使用/etc/my.ini以下两行编辑：

  • innodb_flush_method=nosync
  • innodb_flush_log_at_trx_commit=2

然后重新启动 MariaDB 并重试恢复。现在应该快多了。

恢复后，删除以上行否则您的数据库将寿命短且不好：刷新/同步存在非常重要的原因。虽然关闭它们以进行恢复是可以接受的，但生产数据库应该绝不没有它们就跑。

答案2

如果您的底层存储是普通的旧磁盘，对于磁盘上 25GB 的 MySQL 数据库来说，经历数小时的恢复是很正常的 - 特别是对于一些结构不良的数据库（大量元组、索引等）。

首先压缩你的转储，这可以节省大量的 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

除了系统性能（存储、RAM 等）之外，MySQL 设置也可能产生巨大影响。但这是一门专业知识，没有什么可以通过 ServerFault 问题来解决……

答案3

您可以检查日志中是否有类似这样的行

Could not increase number of max_open_files

请检查您的 中的LimitNOFILE和设置。更改运行和后。您不必将其设置为，但标准值可能太低。LimitMEMLOCK/usr/lib/systemd/system/mysqld.servicesudo systemctl daemon-reloadsudo service mysql restartinfinity

此外，设置为infinity受内核设置限制的值。

也可以看看：

相关内容