我们计划实施一个四节点 MySQL 集群，并考虑使用 SSD 作为存储。我们希望从小型集群中获得高性能和极低的磁盘 IO 延迟，因此我们正在考虑 SSD。有没有人有在 SSD 上使用 MySQL 或 MySQL 集群的经验，或者有构建 SSD raid 组的经验，可以分享他们的经验或想法吗？
答案1
如您所知，SSD 性能出色，非常适合高吞吐量条件。对于数据库服务器，它们非常适合存储事务日志以及任何经常访问的索引，并且能够非常快速地处理查询。
TRIM，不是世界末日
TRIM 对于数据库来说并不那么重要，原因如下：
- 数据库往往属于“少量、大文件”类型的数据。根据您如何看待 SHRINK，这些文件可能会或可能不会变小。
- 事务日志不断地被写入、清除和重写。
- Linux 没有即时 TRIM 支持，因为它都是按需的。
- FSTrim 在定位已删除的块时会使 I/O 静止，这可能会导致其执行过程中出现暂时的延迟峰值。
第三点值得注意。由于 TRIM 是按需的，因此fstrim在清除事务日志后，您会立即获得最佳性能调用。但是，它会引入一个短暂的时间段，在此期间无法提交对事务日志卷的 I/O。如果您对此非常敏感，以至于为此使用了 SSD，那么这样的事件可能会让您无法接受。
由于 TRIM 是一个次要功能，您可以忽略大多数 RAID 控制器尚不支持它的事实，以及除最新的 Linux 内核（比 2.6.39 IIRC 更新）之外的所有内核都可以在软件中支持它的事实。
质量至上
需要注意的最重要的事情之一是你使用企业级SSD 驱动器。这些是基于 MLC 闪存的磁盘，具有高耐久性闪存单元（约 30-40K 次擦除/编程周期），以及大量备用块来处理块磨损。如果您出于某种原因使用 SSD，那么您将对这些 SSD 进行高吞吐量计算，因此您需要在不到一年的时间内不会出现故障的设备。这些设备将帮助您实现这一目标。
SLC 闪存实际上更好（100K+ 擦除/编程周期），但价格差异是促使人们转向 MLC 的原因。是的，他们现在确实制造企业级 MLC！但如果您的驱动器要全力运行 3 年，SLC 将使您的设备使用寿命更长。
对齐和 RAID
块对齐非常重要，因为它会影响您的磨损。这就是 RAID 卡可能出错的地方，也是为什么有些 RAID 卡规格表指出它们不适用于 SSD，尽管如果您将一对连接到它们，它们会很乐意这样做。如果每个块写入都会导致闪存的双重写入，那么您的磨损会更快。理想情况下，您希望 RAID 条带边界落在擦除块大小边界上。
然而，随着每一代固态硬盘的推出，它们在处理磨损方面变得越来越智能。随着固态硬盘本身变得越来越智能，对同一组逻辑集群进行写入操作的破坏性也越来越小。
对于软件 RAID，Linux 和支持实用程序已经支持一些 SSD 好几年了。最新的内核已经很多比目前 Enterprise Linux 领域提供的支持更好，所以请注意。LVM 已经支持 TRIM（因此支持 SSD）好几年了。MD-RAID 最近才获得 TRIM。XFS 和 Btrfs 在 2.6.39 中获得 TRIM 支持，EXT 在 2.6.36 获得稳定支持，并在 20 世纪 20 年代末获得实验性支持。
成对更换
由于磨损的工作原理，镜像对中的一对 SSD 会同时发生故障。因此，当其中一个发生故障时，尽快更换。