Bob*_*way 5 mysql database restore database-restore
我正在将一个大型(~80GB)数据库从它的测试平台移到它的生产环境中。我们正在研究 Windows 服务器。这是我们第一次使用 MySQL,我们仍在学习预期的行为。
我们备份了数据
mysqldump -u root -p --opt [database name] > [database name].sql
Run Code Online (Sandbox Code Playgroud)
这花了大约 3 个小时并创建了一个 45GB 大小的文件。它在一夜之间复制到它的新家,第二天早上,我使用 MySQL Workbench 启动了恢复。根据其日志,它运行
mysql.exe --defaults-file="[路径]\tmpc8tz9l.cnf" --protocol=tcp --host=127.0.0.1 --user=[me] --port=3306 --default-character-set =utf8 --comments --database=[数据库名称] < "H:\[数据库名称].sql"
它正在工作 - 如果我连接到实例,我可以看到数据库和它的一些表。
问题是,它似乎需要永远。我认为它会在与备份相同的 3-4 个时间范围内恢复,可能更快,因为它正在恢复到具有 SSD 驱动器的更强大的服务器上。
但是现在已经过了大约 36 个小时,因为恢复开始了,而且 DB 的大小显然是 30GB。随着它的进行,它似乎变得越来越慢。
现在它已经开始工作了,我不想打断它,所以我想我只需要等待。但供日后参考:这种蜜糖缓慢的恢复速度正常吗?下次我们需要恢复大数据库时,我们可以做些什么来改善问题?
众所周知,非常大的进口产品很难快速生产。听起来你的导入速度变慢了——每秒处理的行数越来越少——随着它的进行。这可能意味着 MySQL 正在检查每个新行以查看它是否与已插入的行存在键冲突。
您可以做以下几件事:
在开始之前,禁用密钥检查。
SET FOREIGN_KEY_CHECKS = 0;
SET UNIQUE_CHECKS = 0;
Run Code Online (Sandbox Code Playgroud)
结束后恢复您的密钥检查。
SET UNIQUE_CHECKS = 1;
SET FOREIGN_KEY_CHECKS = 1;
Run Code Online (Sandbox Code Playgroud)
并且,如果您可以将每几千行INSERT操作包装在
START TRANSACTION;
INSERT ...
INSERT ...
...
COMMIT;
Run Code Online (Sandbox Code Playgroud)
您将节省大量磁盘搅动。
请注意,这仅适用于具有数千行或更多行的表。
mysqldump可以创建一个禁用密钥的转储。 https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_disable-keys
mysqldump --disable-keys
Run Code Online (Sandbox Code Playgroud)
相似地,
mysqldump --extended-insert --no-autocommit
Run Code Online (Sandbox Code Playgroud)
将使转储的 sql 文件包含我关于使用事务的建议的一个变体。
在您的情况下,如果您使用过,--opts --no-autocommit您可能会获得最佳转储文件。您已经使用了--opts.