找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 1922|回复: 0

加快MySQL逻辑恢复速度的方法和参数总结

4

主题

5

帖子

5

积分

贫民

积分
5
JenMinZhang 发表于 2014-2-14 08:48:40 | 显示全部楼层 |阅读模式
日常工作中经常会有需要从mysqldump导出的备份文件恢复数据库的情况,相比物理备份恢复这种方式在恢复时间上往往显得力不从心。
本文就总结了几个对于逻辑备份恢复有加速作用的参数和操作
注意:我们的大前提是,恢复的目标数据库在恢复完成前,没有对外部提供服务
1. 参数调整
log-bin=OFF
恢复时开启二进制日志显然是无意义的,增加了不必要的IO。因此关闭该选项

sync_binlog=0
如果关闭了二进制日志,则这个选项不调整。
但如果因为特殊原因不能关闭二进制日志时,可以考虑减少binlog的fsync来减少磁盘IO压力。

Innodb_buffer_pool_size 尽可能大
尽可能大的配置Innodb_buffer_pool_size 来保证更多的脏页能够存在于BP中,增大潜在的写入合并的可能性,从而减少了磁盘的IO。

Innodb_logfile_size=1G 或更大
增大redolog的体积可以推迟blocking checkpoint发生的时间,也一定程度缓解adaptive flush的刷写频率。
调整这个参数对于恢复表体积远大于Innodb Buffer Size时非常有用。

Innodb_doublewrite=OFF
由于不存在宕机风险(即使宕机,也就是重新再恢复一次),所以doublewrite也可以不需要了。

Innodb_flush_log_at_trx_commit=0
同上,由于不存在宕机风险,无需那么卖力的刷写redo log。

Innodb_flush_neighbors=1
由于逻辑导入更多的是顺序写入,打开flush neighbor以后不单能把IO pattern更贴近顺序。同时,innodb的内部逻辑也会把多个page合并成一次IO进行提交,刷写性能更高。

2. 其他操作
当然对于逻辑恢复速度影响最大的还是索引的计算。
如果是5.5以后或者percona 5.1以后的版本,建议先建表,导入数据,最后创建索引这样的方式进行恢复。因为这些版本的create index或者alter table对于索引的创建做了优化处理。直接在数据上进行计算生成索引,而不是通过新建一张临时表、插入、替换老表的这种土掉渣的方式创建索引。                                                               
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表