首页 > MySQL, MySQL Innodb, database > 使用SSD跑InnoDB注意事项及解决方案

使用SSD跑InnoDB注意事项及解决方案

相信有不少同仁已经做过过SSD作为存储对IO瓶颈的数据库性能测试,在得到可喜的成绩之余,在用于生产环境之前需要解决一些问题。

InnoDB共享表空间包含:
Data dictonary
Double write buffer
Insert buffer
Rollback segments
UNDO space

其中为了实现在脏数据异步回写到磁盘的过程中不造成页面(page)完整性问题,默认2M大小的Innodb的Double write buffer在做checkpoint的过程中会不停的擦写,而当前SSD对固定区域的读写次数是有限制的(比如200万次),这将造成这块区域在很短的时间内损坏。同样,InnoDB的redo log也会进行循环写操作,只因为大小可以设置,一般比Double write buffer要大上很多,损坏会慢一点。

因此如果我们打算在生产环境使用SSD,那么我们可以将 Redo log 和 Double write buffer设置指定到具有电池模块,能开启WB策略的Raid上,从而避免问题的出现。Redo log的配置不难,那么Double write buffer怎么处理? percona新发布的MySQL版本提供percona_innodb_doublewrite_path 参数,可以将Double write buffer单独指定到独立位置,从而将问题加以解决。

AD:
1:MySQL实验室将组织一批志同道合的朋友共同翻译、创作和维护MySQL中文参考手册,以最新的GPL MySQL英文文档为基础。新的内容我们根据实际情况自行添加和维护,并且计划提供comment功能,帮助充实文档内容,欢迎英文基础较好并且有相关经验的朋友参加。文档将在 http://www.mysqlab.net/docs/ 同步发布。
2:MySQL实验室网站放在美国加州, 需要稳定的CDN(目前2M带宽即可)赞助,有好心人请联系QQ:55300231。
3:MySQL实验室BLOG将有新作者/译者加盟,将翻译/创作一些国外优秀的文章和博客。
4:如果免费提供监控报警应用,是愿意开放一个限制权限的帐号,还是愿意安装agent(提供能多的监控服务)?

Related posts:

  1. Inniostat – InnoDB IO Statistics
  2. InnoDB plugin 1.0.7
  3. InnoDB Plugin 1.0.4 for MySQL 5.1.37
  4. Raid1+0 stripe size for MySQL InnoDB
  5. Innodb如何查看剩余表空间?
  6. MySQL Cluster Checkpointing
  1. 2010年6月23日07:27 | #1

    呵呵,可惜??s/可惜/可喜/g ???
    s/自信添加/自行添加/g ??
    要注意错别字哦

  2. kevinbin
    2010年6月25日09:24 | #3

    使用一个受限账户要更安全些,更容易被接受

    • 2010年6月25日14:55 | #4

      谢谢反馈,准备提供2种方案,可以根据自己喜好选择。

  3. Peter Li
    2010年6月25日12:36 | #5

    percona_innodb_doublewrite_path 这个参数有必要吗?

    doblewrite buffer在undo tablespace里面只需要制定innodb_data_home_dir就可以讲ibdata文件给指定到别的位置了。

  4. vox
    2010年7月3日11:13 | #7

    现在的ssd硬盘都有Wear Leveling技术吧,应该不会对某块区域频繁擦写

    • 2010年7月4日10:23 | #8

      这是在其上文件系统的算法实现,为了性能这样做对InnoDB并不是最优方法。

  5. vox
    2010年7月7日17:33 | #9

    @谭俊青

    这个技术应该是写在ssd的主控芯片里面的,现在主流的ssd的控制芯片里面都有吧,只是算法不同

  6. 2010年7月8日06:56 | #10

    @vox
    vox, 你好,欢迎指出问题所在。刚查了下 wear leveling一些资料,了解到确实现在SSD基本上都在新片片上实现了wear leveling算法,在空闲空间循环做写操作,从而提升SSD整体的使用寿命。
    我姑且给个说得过去、自圆其说的理由:SSD如果空闲空间足够大,并且数据库写操作很少发生,那么直接用有wear leveling算法的SSD应该问题不大;如果生育空间不是很充裕,加上写操作频繁,因为脏数据回写是将这个个页面的数据全部写入,如果再加上adaptive flushing的话,这个写操作的量是很大的,按照10000万次计算,30GB大小的空间2个月也就坏了,不知道现在SSD存储元件安全擦写次数是多少。
    另外值得一提的是,将redo log和double write buffer放在由电池保护的drr内存盘上算是最佳方案了。

  7. gary
    2010年7月18日12:59 | #11

    最佳方案,我想是把顺序io放到非ssd盘上. 随机io放到ssd上.
    没有很强烈的理由把顺序读写放ssd上.
    随机/io的:
    table files (*.ibd) #启用了innodb_file_per_table 参数
    undo segments (ibdata)
    顺序io的:
    redo log files (ib_logfile*)
    binary log files (binlog.xxxxxxx)
    doublewrite buffer (ibdata)
    insert buffer (ibdata)
    slow query logs,error logs,general query logs等等.
    由于我从来不用innodb_file_per_table(只是个人喜好),所以不方便测试.哪位同学有条件不妨配置生产环境上试试.对比下性能测试结果.

  1. 本文目前尚无任何 trackbacks 和 pingbacks.