☰

mysql恢复过程需要更长的时间

tag-icon • tag-icon mysql database
mysql恢复过程需要更长的时间

我有一台 Ubuntu 8.04 机器，它有大约 300 GB 大小的mysql数据库。我已使用mysqldump以下命令转储了所有数据库。

mysqldump -u root -p --all-databases > file.sql

现在，在 RHEL6 机器中，我尝试mysql使用以下命令恢复数据库：

mysql -u root -p < file.sql

然而，上面的命令似乎花费了很多时间，并且似乎永远执行下去。 3 天后，当我检查恢复的数据库大小时，显示恢复的数据库大小仅为 30 GB。

有没有一种有效的方法来恢复数据库？

答案1

在发布答案之前，我想重申我问了我的问题这里和这里。正如有人可能暗示的那样，这个问题属于数据库管理员。但我将其发布在这里的原因是因为它涉及编辑/etc/my.cnf.

第一个解决方案

编辑/etc/my.cnf以包含以下参数。配置文件位置可能因 Linux 发行版而异。在 RHEL6 中，它位于/etc/my.cnf.

innodb_doublewrite = 0
innodb_flush_log_at_trx_commit = 0
innodb_support_xa = 0
innodb_locks_unsafe_for_binlog = 1

此建议由德罗伯特我要感谢他提出这个解决方案。

测试：虽然没有恢复命令那么慢mysql，但这种方法仍然需要相当长的时间。该命令执行了 3 天，已恢复约 130 GB。

第二种解决方案

通过在导入数据库转储之前设置几个标志，我们可以显着加快恢复过程：

SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;

需要在.sql文件中设置上述标志。由于我们禁用了自动提交，因此我们还需要在恢复结束时手动提交：

COMMIT;

上面的语句应该是.sql文件的最后一条语句。实际上我们可以找到一个脚本来执行mysqldump以下操作这里。

我没有机会测试这个解决方案，但它很有意义，因为它禁用了外键检查。

由于我们要恢复整个数据库，因此可以通过禁用唯一检查和外键检查来加快速度。此外，通过在恢复结束时提交所有内容，而不是在恢复正在进行时提交，我们可以获得显着的额外速度提升。

第三种解决方案

mysql我备份了整个数据目录。数据目录通常位于/var/lib/mysql.就我而言，数据目录作为单独的分区安装在/mounts/mysql.我已经备份了整个文件夹，因此我将整个文件夹恢复到较新的 RHEL6 计算机。在恢复之前，我们必须确保守护mysqld进程没有启动。虽然我使用rsync命令进行了恢复，但我想确保当前在新的 RHEL6 计算机中设置了文件权限。因此，在恢复/mounts/mysql到新的 RHEL6 系统后，我发出了以下命令。

chown -R mysql:mysql /mounts/mysql

现在，我测试了数据库，一切看起来都非常酷。恢复时间约为3小时。

我还没有看到有人在任何地方建议使用上述方法进行mysql数据库恢复。我看到从这答案是mysql版本必须兼容才能从数据目录恢复数据库。然而，根据我迄今为止的修复经验，事实并非如此。只要权限设置正确，数据库就可以正常工作。

但是，.sql当我们尝试将数据库恢复到数据库或数据库mysql中时，我们需要该文件。 sql-serverpostgre

相关内容