我有一个MySQL数据库，在10分钟内转储到一个3.5 GB的备份（mysqldump）。
但是在备用/testing服务器上重新加载这个备份需要将近2个小时[最初是12次调整之前]。
什么是最大化重新加载性能的一些设置？
最有希望的似乎是innodb_buffer_pool_size，innodb_additional_mem_pool_size和innodb_log_buffer_size …但我达到了我的试错法的极限。 哪些设置“应该”是最重要的？
通过反复试验，我无法获得70％以上的CPU利用率和63％的内存利用率。 我希望100％在重新加载。
所有的表都是InnoDB。
UPDATE
使用这些设置，我可以将加载时间从12小时减less到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 innodb_file_per_table key_buffer = 32M max_allowed_packet = 32M
testing服务器是一个512MB的Rackspace云服务器。
生产服务器是一个2GB的Athlon 64 X2 4200。
mysql Ver 14.12 Distrib 5.0.67, for debian-linux-gnu (i486) using readline 5.2
我不知道现在可以调整多less…但它仍然让我感到担心，只有63％的可用内存在加载过程中被我的mysqld利用。
我不认为这是一个磁盘I / O绑定问题。 同一台服务器可以从一个zip文件复制20MB / s。 所以，使用一些粗略的math，1小时55分的6分钟可以归因于磁盘延迟。 所以这真的应该是CPU限制或内存限制，但这两者都不会达到100％。
我发现innodb_flush_log_at_trx_commit对恢复速度有最大的影响。 确保它被设置为2，至less在恢复过程中。
除此之外，检查上面提到的lg的maatkit工具，dump / restore很简单，但不是很平行，只有mk_parallel_restore可以充分利用你的cpu
你可以试试mk-parallel-restore
也许不同的备份方法？ 我假设你想在另一台服务器上恢复完整的数据库服务器。 如果您的机器上有LVM，则可以使用LVM快照并复制原始数据库文件。 另一个（也可能更好）选项是使用xtrabackup而不是mysqldump。