数据库(MySQL)和SSD寿命 – 写入数据库的“大量”

在我工作的公司里,我们开始使用SSD作为我们内部的3GB MySQL数据库

性能差异是巨大的,这是伟大的。

我担心的是SSD的寿命

写入数据库是24小时/ 7天,很less读取。

我应该担心SSD的使用寿命吗?

  • 数据库(二进制文件)大小为3 GB,MySQL,InnoDB表
  • 硬盘大小为250 GB(RAID 1)
  • 我们约24小时/每分钟进行100次UPDATE / INSERT的操作
  • 我们做约10-20行UPDATE / INSERT的每分钟24h / 7

更新:(更多的数据)

  • SSD正在使用: SAMSUNG 250GB 840 Evo SATA III
  • 软件RAID(mdadm)
  • 系统:CentOS 6.4
  • MySQL版本:5.4

更新2:

  • 没有TRUNCATE查询被执行
  • 每日统计:大量的更新(> 300k),<50 DELETE'S,数据库正在增长的很lessINSERT的〜7-10 MB /天

10 MB /天= 4 GB /年。 如果使用ext4和TRIM格式化,没有其他数据保存在SSD(尤其是交换),则需要ca. 200GB / 4GB * 2 =一个(!)完整的RW周期为100年,SSD可承受数千次。

按照一般build议,启用TRIM,没有问题: https : //wiki.archlinux.org/index.php/Solid_State_Drives

在你的情况下,问题可能在RAID中。 Centos 6.4中的LVM通过/etc/lvm/lvm.conf支持带有issue_discards选项的TRIM。 mdraid – doesnt(请参阅RHEL固态磁盘部署指南 )

在全球范围内,我从来没有听说过由于内部重新分配准备金耗尽而导致的SSD死机,我只在Linus Torvald的SSD死亡时才读过它( https://plus.google.com/+LinusTorvalds/posts/V81f6d7QK9j )。 我使用一些旧的(也许是第一代)型号作为服务器上的硬件RAID的块caching,并且冲刷率更高,运行几年。

对于其他人的疑惑,是的,如果TRIM不被支持的话,那么你会在840 EVO驱动器上遇到可怕的性能损失。 我们有生产中的服务器,全天候写入,性能大幅下降,大约是新硬盘的10%。

我非常不满意我们的托pipe服务提供商在生产服务器上放置消费级硬盘。 好的SSD是英特尔S3500 / S3700。