SSD 上的 MySQL 集群
我們計劃實施一個四節點 MySQL 集群，並正在考慮使用 SSD 作為儲存。我們希望從小型集群中獲得高水平的性能和非常低的磁碟 IO 延遲，因此我們正在研究 SSD。有沒有人對 SSD 上的 MySQL 或 MySQL Cluster 有任何經驗，或者建立 SSD RAID 組來分享他們的經驗或想法？
如您所知，SSD 是惡魔表演者，非常適合高吞吐量條件。對於數據庫伺服器，它們可以很好地容納事務日誌以及任何經常命中的索引，此外還可以非常快速地提供查詢。
TRIM，不是世界末日
由於以下幾個原因，TRIM 對於數據庫並不那麼重要：
- 數據庫往往是“少數大型文件”類型的數據。根據您查看 SHRINK 的方式，這些文件可能會或可能不會變小。
- 事務日誌不斷被寫入、清除和重寫。
- Linux 沒有即時 TRIM 支持，因為它都是按需提供的。
- FSTrim 在定位已刪除的塊時會暫停 I/O，這可能會在它執行其操作時導致暫時的延遲峰值。
第三點值得關注。由於 TRIM 是按需提供的，因此
fstrim在您清除事務日誌後，您將立即獲得最佳性能呼叫。但是，它會引入一個短暫的時間段，在該時間段內，您的 translog 卷的 I/O 無法送出。如果您足夠敏感以至於您為此使用 SSD，那麼這樣的事件可能會破壞您的交易。因為 TRIM 是一個次要功能，您可以忽略大多數 RAID 控制器還不支持它的事實，以及除了最新的 Linux 核心（比 2.6.39 IIRC 更新）之外的所有核心都可以在軟體中支持它的事實。
質量很重要
要注意的最重要的事情之一是您使用企業級SSD 驅動器。這些是基於 MLC 快閃記憶體的磁碟，具有高耐用性快閃記憶體單元（約 30-40K 擦除/程式週期），以及大量備用塊以處理塊磨損。如果您出於某種原因使用 SSD，那麼您將對它們進行高吞吐量計算，因此您需要在不到一年的時間內不會出現故障的設備。這些會讓你到達那裡。
SLC 快閃記憶體實際上更好（100K+ 擦除/程式週期），但價格差異是促使人們選擇 MLC 的原因。是的，他們現在確實生產企業級 MLC！但是，如果您的驅動器打算用完 3 年，SLC 將使您的設備使用壽命更長。
對齊和 RAID
塊對齊很重要，因為它會影響您的穿著。這就是 RAID 卡可能出錯的地方，以及為什麼一些 RAID 卡規格表聲明它們不能與 SSD 一起使用，即使如果您將一對連接到 SSD 上它們會很樂意這樣做。如果每個塊寫入都會導致對快閃記憶體的雙重寫入，那麼您會磨損得更快。理想情況下，您希望 RAID 條帶邊界落在擦除塊大小邊界上。
然而，隨著每一代新產品的問世，SSD 在處理磨損方面變得更加智能。隨著 SSD 本身變得越來越智能，用寫入衝擊同一組邏輯集群的破壞性越來越小。
對於軟體 RAID，Linux 和支持實用程序已經有幾年的 SSD 支持。最新的核心比現在企業 Linux 領域的核心提供更好的支持，所以請注意*。*LVM 已經支持 TRIM（以及 SSD 感知）已有幾年了。MD-RAID 最近才獲得 TRIM。XFS 和 Btrfs 在 2.6.39 獲得了 TRIM 支持，EXTs 在 2.6.36 獲得了穩定的支持，並在 20 年代後期獲得了實驗性支持。
成對更換
由於磨損的工作原理，鏡像對中的一對 SSD 將幾乎同時發生故障。所以當一個去的時候，盡快把兩個都換掉。