SBh*_*ani 104 mysql innodb mysqldump backup
我有这个巨大的 32 GB SQL 转储,我需要将其导入 MySQL。我以前不必导入如此庞大的 SQL 转储。我做了通常的:
mysql -uroot dbname < dbname.sql
Run Code Online (Sandbox Code Playgroud)
时间太长了。有一个大约有 3 亿行的表,在大约 3 小时内达到了 150 万行。因此,整个过程似乎需要 600 小时(即 24 天)并且不切实际。所以我的问题是,有没有更快的方法来做到这一点?
innodb_flush_log_at_trx_commit = 2建议的设置似乎没有(明显可见/指数级)改进。Rol*_*DBA 130
Percona 的 Vadim Tkachenko 制作了 InnoDB 的精美图片表示

您肯定需要更改以下内容
innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 0
Run Code Online (Sandbox Code Playgroud)
为什么要进行这些设置?
.ibd文件的服务写入操作。根据 上的MySQL 文档Configuring the Number of Background InnoDB I/O Threads,每个线程最多可以处理 256 个待处理的 I/O 请求。MySQL 的默认值为 4,Percona Server 的默认值为 8。最大值为 64。像这样重启mysql
service mysql restart --innodb-doublewrite=0
Run Code Online (Sandbox Code Playgroud)
这将禁用 InnoDB 双写缓冲区
导入您的数据。完成后,正常重启mysql
service mysql restart
Run Code Online (Sandbox Code Playgroud)
这将重新启用 InnoDB 双写缓冲区
试一试 !!!
小智 15
您真的需要恢复整个数据库吗?如果你不这样做,我的2c:
您可以提取特定表以对“块”进行还原。像这样的东西:
zcat your-dump.gz.sql | sed -n -e '/DROP TABLE.*`TABLE_NAME`/,/UNLOCK TABLES/p' > table_name-dump.sql
Run Code Online (Sandbox Code Playgroud)
我做了一次,提取我需要的表花了大约 10 分钟 - 我的完整恢复花了 13 到 14 个小时,有 35GB(gzip 压缩)转储。
在/pattern/,/pattern/p与-n参数,使“模式之间的”片-包括他们。
无论如何,为了恢复 35GB,我使用了 AWS EC2 机器 (c3.8xlarge),通过 yum (Centos) 安装了 Percona,并刚刚添加/更改了以下几行my.cnf:
max_allowed_packet=256M
wait_timeout=30000
Run Code Online (Sandbox Code Playgroud)
我认为数字太高了,但对我的设置有用。
小智 7
导入数据库的最快方法是将( .frm, .MYD, .MYI )文件(如果是 MyISAM)直接复制到 /var/lib/mysql/“数据库名称”。
否则你可以尝试: mysql > use database_name; \. /path/to/file.sql
这是导入数据的另一种方式。
小智 6
帮助加快导入速度的一种方法是在导入时锁定表。使用 mysqldump 的 --add-locks 选项。
mysqldump --add-drop-table --add-locks --database db > db.sql
Run Code Online (Sandbox Code Playgroud)
或者你可以使用--opt打开一些有用的参数,这会为转储打开一堆有用的东西。
mysqldump --opt --database db > db.sql
Run Code Online (Sandbox Code Playgroud)
如果服务器上有另一个存储设备,请使用它 - 从一个设备复制到另一个设备是加速传输的一种方法。
您还可以使用--ignore-table过滤掉不需要的表
| 归档时间: |
|
| 查看次数: |
147062 次 |
| 最近记录: |