我有一个 MySQL 数据库，大约 10 分钟后转储为 3.5 GB 的备份（mysqldump）。
但是在备用/测试服务器上重新加载此备份需要将近 2 个小时 [在进行一些调整之前原本是 12 个小时]。
哪些设置可以最大程度地提高重新加载性能？
最有希望的似乎是 innodb_buffer_pool_size、innodb_additional_mem_pool_size 和 innodb_log_buffer_size...但我的反复试验方法已经到达极限。这些设置中哪一个“应该”是最重要的？
通过反复试验，我无法获得超过 70% 的 CPU 利用率和 63% 的内存利用率。我希望在重新加载期间两者都达到 100%。
所有表都是 InnoDB。
更新
通过以下设置，我能够将加载时间从 12 小时减少到 1 小时 55 分钟：
innodb_buffer_pool_size=192M innodb_additional_mem_pool_size=96M innodb_flush_log_at_trx_commit = 0 复制代码 innodb_log_buffer_size=64M 表 1. innodb_file_per_table 密钥缓冲区 = 32M 最大允许数据包 = 32M
测试服务器是 512MB Rackspace 云服务器。
生产服务器是2GB Athlon 64 X2 4200。
mysql Ver 14.12 Distrib 5.0.67, for debian-linux-gnu (i486) using readline 5.2
我不确定现在还能进行多少调整...但在加载过程中，mysqld 仅使用了 63% 的可用 RAM，这仍然令我感到困扰。
我不认为这是磁盘 I/O 受限的问题。同一台服务器可以以 20MB/s 的速度从 zip 文件复制。因此，通过粗略计算，1 小时 55 分钟中只有 6 分钟可以归因于磁盘延迟。因此，这实际上应该是 CPU 受限或内存受限，但两者都不会达到 100%。
答案1
我发现 innodb_flush_log_at_trx_commit 对恢复速度影响最大。确保至少在恢复期间将其设置为 2。
除此之外，请检查 lg 上面建议的 maatkit 工具，转储/恢复很简单，但不是很并行，只有 mk_parallel_restore 可以充分利用你的 CPU
答案2
你可以试试mk-并行-恢复