我想使用 mysqldump 和 MySQL 5.1 创建一个包含大约 40 个 InnoDB 表和大约 1.5GB 数据的数据库副本。
什么是可以最快转储和加载数据的最佳参数(即:--single-transaction)?
同样,将数据加载到第二个数据库时,是否更快:
1) 将结果直接传送到第二个 MySQL 服务器实例并使用 --compress 选项
或者
2)从一个文本文件中加载它(即:mysql < mysql_dump.sql)
对 mysqldump 使用“-T”选项会在指定目录中生成大量 .sql 和 .txt 文件。转储大型表比使用 INSERT 语句的单个 .sql 文件快约 50%(减少 1/3 的挂钟时间)。
此外,如果您可以并行加载多个表并使多个核心饱和,则在恢复时会有巨大的好处。在 8 核机器上,除了“-T”提供的效率改进之外,恢复转储的挂钟时间可能相差 8 倍。因为“-T”会导致每个表存储在一个单独的文件中,所以并行加载它们比拆分一个庞大的 .sql 文件更容易。
将上述策略发挥到极致,可以创建一个脚本来并行广泛地转储数据库。嗯,这正是 Maakit mk-parallel-dump(参见http://www.maatkit.org/doc/mk-parallel-dump.html)和 mk-parallel-restore 工具的内容;对底层 mysqldump 程序进行多次调用的 perl 脚本。但是,当我尝试使用这些时,我很难在没有重复密钥错误的情况下完成还原,而这些错误在原版转储中不会发生,因此请记住,您的里程可能会有所不同。
--single-transaction 开关对于转储实时数据库而无需停顿它或转储从数据库而无需停止从属数据库非常有用。
遗憾的是,-T 与 --single-transaction 不兼容,所以你只能得到一个。
通常,进行转储比恢复它要快得多。仍然有一个工具可以获取传入的整体转储文件并将其分成多个部分以并行加载。据我所知,这样的工具还不存在。
要侦听一台主机上的传入转储,请运行:
nc -l 7878 > mysql-dump.sql
然后在您的数据库主机上,运行
mysqldump $OPTS | nc myhost.mydomain.com 7878
这减少了主机上磁盘轴的争用,将转储写入磁盘稍微加快了转储速度(假设网络速度足以跟上,对于同一数据中心中的两台主机来说这是一个相当安全的假设)。另外,如果您正在构建一个新的从站,这可以节省完成后必须传输转储文件的步骤。
注意事项 - 显然,您需要有足够的网络带宽才能让事情变得难以忍受,如果 TCP 会话中断,您必须从头开始,但对于大多数转储,这不是主要问题。
最后,我想澄清一点常见的困惑。
尽管您在 mysqldump 示例和教程中经常看到这些标志,但它们是多余的,因为它们默认打开:
--opt
--add-drop-table
--add-locks
--create-options
--disable-keys
--extended-insert
--lock-tables
--quick
--set-charset
. 来自http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html:
--opt 的使用与指定 --add-drop-table、--add-locks、--create-options、--disable-keys、--extended-insert、--lock-tables、-- 相同快速和--set-charset。--opt 代表的所有选项也默认打开,因为 --opt 默认打开。
在这些行为中,“--quick”是最重要的行为之一(在传输第一行之前跳过在 mysqld 中缓存整个结果集),并且可以与“mysql”一起使用(默认情况下不会打开 --quick)显着加快返回大型结果集的查询(例如转储大表的所有行)。
将其直接通过管道传输到另一个实例,以避免磁盘开销。除非您在慢速网络上运行,否则不要打扰--compress
,因为在快速 LAN 或环回上,网络开销无关紧要。
我认为如果您尝试数据库复制而不是使用 mysqldump,它会更快并节省磁盘空间。我个人使用sqlyog enterprise来完成我真正繁重的工作,但还有许多其他工具可以提供相同的服务。当然,除非您只想使用 mysqldump。
对于 innodb, --order-by-primary --extended-insert 通常是最好的组合。如果你的每一个最后一点性能和目标框有许多 CPU 内核,你可能想要拆分生成的转储文件并在多个线程中进行并行插入,最多为 innodb_thread_concurrency/2。
此外,将目标上的 innodb_buffer_pool_size 调整到您可以承受的最大值,并将 innodb_log_file_size 增加到 128 或 256 MB(注意这一点,您需要在重新启动 mysql 守护程序之前删除旧的日志文件,否则它不会重新启动)
使用 Maatkit 的 mk-parallel-dump 工具。
至少那可能会更快。我会更信任mysqldump。
你多久做一次?这真的是应用程序性能问题吗?也许您应该设计一种不需要转储整个数据(复制?)
另一方面,1.5G 是一个很小的数据库,所以它可能不会有太大问题。