提高MySQL导入速度

47

我有一个22GB的大型数据库。 我过去使用mysqldump命令以gzip格式进行备份。

当我解压缩gz文件时,它会生成.sql文件,大小为16.2GB

当我尝试在本地服务器中导入数据库时,需要大约48小时才能完成导入。是否有方法可以提高导入速度?

另外,我想知道是否需要进行任何硬件更改来改善性能。

当前系统配置:

 Processor: 4th Gen i5
 RAM: 8GB

#更新

我的.cnf文件如下

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
#
# * Basic Settings
#
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address        = 127.0.0.1
#
# * Fine Tuning
#
key_buffer      = 16M
max_allowed_packet  = 512M
thread_stack        = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit   = 4M
query_cache_size        = 512M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#log_slow_queries   = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id      = 1
#log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size         = 100M
#binlog_do_db       = include_database_name
#binlog_ignore_db   = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet  = 512M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer      = 512M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

已经上传了3天,目前已经导入了9.9 GB。数据库包含MyISAMInnoDB表格。我该怎么做来提高导入性能?

我尝试使用mysqldump将每个表格单独以gz格式导出,并通过执行以下代码的PHP脚本导入每个表格:

$dir="./";
$files = scandir($dir, 1);
array_pop($files);
array_pop($files);
$tablecount=0;
foreach($files as $file){
    $tablecount++;
    echo $tablecount."     ";

    echo $file."\n";
    $command="gunzip < ".$file." | mysql -u root -pubuntu cms";

    echo exec($command);
}

你能接受 MySQL 服务器停机几秒钟吗?如果可以,直接备份 MySQL 数据库文件,恢复时只需将其复制回来即可。这两个操作都需要将 MySQL 服务器离线。这是一种不安全但高效的方式。 - Frederick Zhang
你有多少张表? - Alex
您可以添加更多关于问题的信息 - 瓶颈是CPU还是磁盘,是否有特定的表导致了缓慢的导入;如果是这样,那么表的结构是什么,其中有多少行等。 - VolenD
1
我们有一些大表(10GB),对于MySQL来说,导入/导出太多了。帮助的方法是将大型日志表移动到MongoDB中。我知道这不会解决你的问题,但总有一天你可能需要做出决定。 - Zdenek Machek
我投票关闭这个问题,因为它应该在dba上发布。 - undefined
显示剩余3条评论
11个回答

16

按照描述的方式进行转储和恢复将意味着MySQL在导入数据时必须完全重建索引。它还必须每次解析数据。

如果您可以以MySQL已经了解的格式复制数据文件,那么效率会更高。一种好的方法是使用Percona的innobackupex

(开源并作为XtraBackup的一部分分发,在这里下载)。

这将对MyISAM表进行快照,并为InnoDB表复制底层文件,然后针对这些文件回放事务日志以确保一致状态。它可以在不停机的情况下从活动服务器执行此操作(我不知道这是否是您的要求?)

我建议您阅读文档,但要以最简单的形式进行备份,请使用:

$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
$ innobackupex --apply-log /path/to/BACKUP-DIR/

如果数据在同一台机器上,那么innobackupex甚至有一个简单的恢复命令:

$ innobackupex --copy-back /path/to/BACKUP-DIR

有许多更多的选项和不同的备份方法,因此我真的鼓励您在开始之前仔细阅读文档。

关于速度的参考,我们的慢测试服务器大约有600个IOPS,使用这种方法可以在大约4小时内还原500GB的备份。

最后:您提到了如何加快导入速度。它主要取决于瓶颈在哪里。通常,导入操作是I/O绑定的(可以通过检查io等待来进行测试),而加快速度的方法是提高更快的磁盘吞吐量-无论是更快的磁盘本身还是更多的磁盘协同工作。


13

要完全理解问题的原因,有很多参数是缺失的,例如:

  1. MySQL版本
  2. 磁盘类型和速度
  3. 在开始MySQL服务器之前服务器上的可用内存
  4. mysqldump时的iostat输出。
  5. 首次创建转储文件时使用的参数。

还有很多其他参数需要考虑。

因此,我猜测您的问题出在磁盘上,因为我管理着150个MySQL实例,其中一个实例有3TB的数据,通常磁盘是问题所在。

现在是解决方案:

首先 - 您的MySQL未配置为最佳性能。

您可以在Percona博客文章中阅读有关配置最重要的设置: http://www.percona.com/blog/2014/01/28/10-mysql-settings-to-tune-after-installation/

特别检查以下参数:

innodb_buffer_pool_size 
innodb_flush_log_at_trx_commit
innodb_flush_method

如果您的问题是磁盘读取相同驱动器中的文件会使问题变得更糟。

如果您的MySQL服务器开始交换,因为没有足够的可用RAM - 您的问题将变得更加严重。

在还原过程之前和期间,您需要在计算机上运行诊断程序来找出问题所在。

此外,我可以建议您使用另一种比mysqldump更快的技术来执行重构任务。

这就是Percona Xtrabackup - http://www.percona.com/doc/percona-xtrabackup/2.2/

您需要使用它创建备份,并从备份进行还原,或通过流选项直接从正在运行的服务器重新构建。

此外,MySQL版本从5.5开始,InnoDB比MyISAM表现更快。考虑将所有表更改为InnoDB。


将表从MyISAM更改为InnoDB会影响任何关系吗?或者对我的数据库造成任何损害吗?相比使用InnoDB,使用MyISAM是否有任何特定优势? - dharanbro
如果你问任何一位MySQL专家,他们都会说——没有。今天使用InnoDB比MyISAM更有优势。但是你需要验证使用你的表的代码,并确保它不依赖于MyISAM执行的表锁。 - Tata
标准的mysqldump和导入最大的问题并不是硬盘成为瓶颈,而是在执行此操作时实际上是将所有数据重新插入到表中,而不仅仅是复制数据结构。因此,您必须重新创建结构。这是一个主要的软件限制,由于慢速磁盘而加剧。当涉及备份时,MyISAM比Innodb具有非常明显的优势:您可以简单地锁定和刷新表格,并使用cp或scp复制数据,它可以正常工作(记得将文件chown mysql:mysql)。 - Chris Seline
@ChrisSeline - 你也可以对InnoDB表执行相同的操作,但是这样做会导致你的数据库无法正常工作。不要尝试从生产数据库以这种方式备份1TB的数据。 - Tata
使用InnoDB做这件事情要复杂得多。我曾经尝试过使用scp复制整个带有InnoDB表的数据库,取得了一些成功,但从未成功过单独复制一个表。而且你仍然可以备份生产数据,只是在备份时不能写入该表 :)。总之,我相信这就是Percona工具存在的原因,因为它真的很麻烦! - Chris Seline

9

你可以做的一件事是

SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS=0

你可以尝试更改数值,以达到不同的效果。
innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_flush_method

my.cnf中有一些配置可以帮助你入门,但通常情况下,你应该查看其他InnoDB参数,以了解哪些最适合你。
这是我过去遇到的问题,我觉得我并没有完全解决,但我希望从一开始就指向这个方向。这样可以节省很多时间。

当前正进行常规导入。一旦完成,让我尝试一下这个。 - dharanbro
在my.cnf中设置innodb_buffer_pool_size并不会启动MySQL服务器。 - dharanbro
7
@DharanBro那是因为你拼错了。 - user207421

6

我必须导入一个几乎和你的一样大的转储文件(15.8GB),使用以下设置,我用了2.2小时才完成:

my.cnf:

innodb_buffer_pool_size = 12G
innodb_log_buffer_size = 256M
innodb_log_file_size = 2G
innodb_write_io_threads = 32
innodb_flush_log_at_trx_commit = 0
innodb_doublewrite = 0

我的系统规格如下:

CPU: core i5 7th gen
RAM: 16GB
HDD: 500GB

我已根据我的系统规格配置了这些设置,因为您的系统有8GB内存,所以您可以将其配置类似于以下设置:

innodb_buffer_pool_size = 5G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 0
innodb_doublewrite = 0

您可以尝试不同的配置以查看哪种更适合您。还要记得重新启动您的MySQL以应用更改。

6

确保将您的"max_allowed_packet"变量增加到足够大的大小。如果您有大量文本数据,这将非常有帮助。使用高性能硬件肯定会提高导入数据的速度。

mysql --max_allowed_packet=256M -u root -p < "database-file.sql"

4
配置文件中的max_allowed_packet = 512M,所以将其改为256M实际上会减小其大小。 - Tata

3

我曾经也遇到过同样的问题。我发现使用 mysqldump 命令将数据导出为 CSV 文件(像这样):

mysqldump -u [username] -p -t -T/path/to/db/directory [database] --fields-enclosed-by=\" --fields-terminated-by=,

然后使用mysql客户端中的LOAD DATA INFILE查询导入数据(如下所示):

LOAD DATA FROM INFILE /path/to/db/directory/table.csv INTO TABLE FIELDS TERMINATED BY ',';

执行包含数据的SQL查询相比于仅仅执行SQL查询要快上一个数量级。当然,这也取决于表已经被创建(并且为空)。

当然,您也可以通过先导出再导入您的空模式来完成此操作。


使用-T选项与mysqldump一起的一个重要注意事项是,只有在mysqldump在与mysqld服务器相同的机器上运行时才有效。 - erstaples

3

方法1:按照fakedrake的建议禁用外键。

SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS=0

方法2:使用BigDump,将分块处理你的mysqldump文件,并导入。 http://www.ozerov.de/bigdump/usage/

问题:你说你正在上传?你是如何导入你的dump文件的?不是直接从服务器/命令行导入吗?


2

获取更多的内存,获得更快的处理器,安装SSD以实现更快的写入速度。将插入操作分批处理,这样比单个插入操作运行更快。该文件很大,需要时间来处理。


1

在 [Vinbot 的上面的回答][1] 中描述的方法使用 LOAD DATA INFILE 是我每天在本地桌面上进行分析处理时导入大约 1 Gb 数据的方式(我没有服务器上的 DBA 或 CREATE TABLE 权限,但是我拥有本地 MySQL 的权限)。

mySQL 8.0.17 中引入的一个新功能,[mySQL 并行表导入实用程序][2],将其提升到了下一个级别。

以前需要大约 15 分钟(约 1 Gb)的 CSV 表导入现在只需要 5 分 30 秒,在具有 SATA SSD 的 Intel Core I7-6820HQ 上。当我添加了一个 nVME M.2 1Tb WD Black 硬盘(为旧台式机购买但不兼容)并将 mySQL 安装到该硬盘上时,时间降至 4 分 15 秒。

我在运行实用程序之前定义了大多数表定义中的索引。没有索引的负载甚至更快,但后期索引创建需要更多的总时间。这是有道理的,因为并行加载器的多核特性延伸到索引创建。

我还在并行加载程序脚本中使用了ALTER INSTANCE DISABLE INNODB REDO_LOG(引入8.0.21)。请注意,完成大量加载后不要忘记重新启用此功能。如果不重新启用,可能会导致实例损坏(不仅是表,而是整个实例)。我始终关闭双写缓冲。CPU监视器显示该实用程序充分利用了所有8个核心。完成并行加载后,返回到单线程的mySQL(用于我的线性分析任务集,而不是多用户)。新的nVME可以将时间缩短约10%。该实用程序每天为我节省几分钟的时间。
该实用程序允许您管理缓冲区大小和线程数。我将CPU中的物理核心数量(8)与之匹配,这似乎是最佳选择。(最初我来到这个线程是为了寻找有关配置并行加载器的优化技巧。) [1]: https://dev59.com/I10b5IYBdhLWcg3wEdox#29922299 [2]: https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-parallel-table.html

0

我不确定这对你是否是一种选择,但最好的方法就像Tata和AndySavage已经说过的那样:从生产服务器拍摄数据文件的快照,然后使用Percona的innobackupex将它们安装在您的本地计算机上。 它会以一致的方式备份InnoDb表,并在MyISAM表上执行写锁定。

在生产机器上准备一个完整的备份:

http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html

复制(或通过SSH管道备份时 - 更多信息在这里)备份文件到您的本地计算机并进行恢复:

恢复备份:

http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/restoring_a_backup_ibk.html

您可以在这里找到 innobackupex 的完整文档:http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html 恢复时间比读取 SQL 转储要快得多。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接