提高mysql导入的速度

时间:2015-04-15 07:07:34

标签: mysql linux database-administration

我有22GB的大型数据库。我曾经用gzip格式的mysqldump命令进行备份。

当我提取gz文件时,它会生成.sql

16.2GB文件

当我尝试在本地服务器中导入数据库时​​,导入大约需要48小时。有没有办法提高导入过程的速度?

此外,我想知道是否需要进行任何硬件更改以提高性能。

当前系统配置

 Processor: 4th Gen i5
 RAM: 8GB

#UPDATE

my.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);
}

9 个答案:

答案 0 :(得分:11)

以所述方式执行转储和恢复意味着MySQL必须在导入数据时完全重建索​​引。它还必须每次解析数据。

如果您能够以MySQL已经理解的格式复制数据文件,效率会更高。这样做的好方法是使用Percona的innobackupex

(开源并作为XtraBackup的一部分发布,可从here下载)。

这将拍摄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小时内恢复500 GB备份。

最后:您提到了如何加快导入速度。它主要取决于瓶颈是什么。通常,导入操作受I / O限制(您可以通过检查io等进行测试),加快速度的方法是更快的磁盘吞吐量 - 更快的磁盘本身,或者更多的磁盘一致。

答案 1 :(得分:10)

为了完全理解问题的原因,有很多参数缺失。如:

  1. MySQL版本
  2. 磁盘类型和速度
  3. 启动MySQL服务器之前服务器上的可用内存
  4. 在mysqldump之前和之时输出iostat。
  5. 首先用于创建转储文件的参数是什么。
  6. 还有更多。

    所以我试着猜测你的问题是在磁盘中,因为我有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执行速度更快。考虑将所有表格更改为它。

答案 2 :(得分:6)

你可以做的一件事是

SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS=0

您还可以使用值

innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_flush_method
my.cnf

让你去,但总的来说,你应该看看rest of innodb parameters,看看哪种最适合你。

这是我过去遇到的一个问题,我觉得我没有完全解决这个问题,但我希望自己从这个方向指出了自己。本来可以节省一些时间。

答案 3 :(得分:5)

确保增加&#34; max_allowed_pa​​cket &#34;变量到足够大的尺寸。如果您有大量文本数据,这将非常有用。使用高性能硬件肯定会提高导入数据的速度。

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

答案 4 :(得分:2)

获得更多内存,获得更快的处理器,获得更快的写入速度的SSD。对插入物进行批处理,使它们比一堆单独的插入物运行得更快。这是一个巨大的文件,需要时间。

答案 5 :(得分:2)

方法1:禁用外键,如fakedrake建议的那样。

SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS = 0

方式2:使用BigDump,它会将你的mysqldump文件分块,然后导入它。 http://www.ozerov.de/bigdump/usage/

问题:您说您正在上传?你如何导入转储?不是直接来自服务器/命令行?

答案 6 :(得分:2)

我不得不处理同样的问题。我发现使用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查询快一个数量级。当然,它还取决于已经创建的表(和空)。

您当然也可以先导出然后导入空架构。

答案 7 :(得分:1)

[{Vinbot的答案)[1]中使用LOAD DATA INFILE描述的方法是我每天如何在本地桌面上带来大约1 Gb的分析过程(我没有DBA或{{1 }}拥有服务器上的权限,但我拥有本地mySQL的权限。

mySQL 8.0.17中引入的一项新功能[mySQL并行表导入实用程序] [2]将其带入了一个新的高度。

在具有SATA SSD的Intel Core I7-6820HQ上,以前需要大约15分钟(大约1 Gb)的CSV表导入现在需要5:30。当我添加nVME M.2 1Tb WD Black驱动器(购买用于旧台式机,但事实证明不兼容)并将mySQL安装移动到该驱动器时,时间降至4分15秒。

在运行实用程序之前,我会在表定义中定义大多数索引。没有索引的情况下加载速度甚至更快,但是加载后索引最终会花费更多的总时间。这是有道理的,因为Parallel Loader的多核功能已扩展到索引创建。

我也在并行装载程序实用程序脚本中CREATE TABLE(引入8.0.21)。注意警告,不要在完成大容量装载后将其保留。我没有重新启用,最终导致实例损坏(不仅仅是表,而是整个实例)。我始终保持双重缓冲功能。

CPU监视器显示该实用程序完全利用了所有8个内核。

使用并行加载程序完成后,它又回到了单线程mySQL(用于我的线性分析任务集,而不是多用户)。新的nVME将时间减少了10%左右。该实用程序每天为我节省几分钟。

该实用程序允许您管理缓冲区大小和线程数。我匹配了CPU(8)中的物理核心数量,这似乎是最佳选择。 (我最初来到此线程的目的是寻找有关配置并行加载器的优化技巧)。 [1]:https://stackoverflow.com/a/29922299/5839677 [2]:https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-parallel-table.html

答案 8 :(得分:0)

我不确定它是否适合您,但最好的解决方法是Tata和AndySavage已经说过:从生产服务器获取数据文件的快照,然后将它们安装在本地盒子上通过使用Percona的innobackupex。它将以一致的方式备份InnoDb表并在MyISAM表上执行写锁定。

在生产计算机上准备完整备份:

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

复制(或通过SSH进行备份时管道 - 更多信息here)备份文件到本地计算机并恢复它们:

恢复备份:

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转储要快得多。

相关问题