本節說明當您可以為資料庫伺服器配置更多且更快速的儲存硬體時,配置儲存裝置的方法。如需有關優化 InnoDB
配置以提升 I/O 效能的資訊,請參閱第 10.5.8 節,「優化 InnoDB 磁碟 I/O」。
磁碟搜尋是效能的巨大瓶頸。當資料量開始變得非常大,以致於無法進行有效的快取時,這個問題會變得更加明顯。對於您或多或少隨機存取資料的大型資料庫,您可以確定您至少需要一次磁碟搜尋才能讀取,以及幾次磁碟搜尋才能寫入。為了將此問題降至最低,請使用搜尋時間較短的磁碟。
透過將檔案符號連結至不同的磁碟或條帶化磁碟,增加可用的磁碟主軸數量 (並藉此減少搜尋額外負荷)
使用符號連結
這表示,對於
MyISAM
資料表,您將索引檔案和資料檔案從其在資料目錄中的慣常位置符號連結至另一個磁碟 (該磁碟也可以是條帶化的)。假設該磁碟也未用於其他用途,這會使搜尋和讀取時間都更好。請參閱第 10.12.2 節,「使用符號連結」。不支援將符號連結用於
InnoDB
資料表。但是,可以將InnoDB
資料和日誌檔案放置在不同的實體磁碟上。如需更多資訊,請參閱第 10.5.8 節,「優化 InnoDB 磁碟 I/O」。條帶化表示您有多個磁碟,並將第一個區塊放在第一個磁碟上,將第二個區塊放在第二個磁碟上,依此類推,將第
N
個區塊放在 (
) 磁碟上。這表示如果您的正常資料大小小於條帶大小 (或完全對齊),您將獲得更好的效能。條帶化非常依賴作業系統和條帶大小,因此請使用不同的條帶大小對您的應用程式進行基準測試。請參閱第 10.13.2 節,「使用您自己的基準測試」。N
MODnumber_of_disks
條帶化的速度差異非常依賴於參數。根據您設定條帶化參數和磁碟數量的不同,您可能會獲得以數量級測量的差異。您必須選擇針對隨機或循序存取進行優化。
為了可靠性,您可能想要使用 RAID 0+1 (條帶化加上鏡像),但在這種情況下,您需要 2 ×
N
個磁碟機才能保存N
個磁碟機的資料。如果您有錢,這可能是最佳選擇。但是,您可能還必須投資一些磁碟區管理軟體才能有效處理它。一個好的選項是根據資料類型的關鍵程度來調整 RAID 等級。例如,將可以重新產生的半重要資料儲存在 RAID 0 磁碟上,但將真正重要的資料 (例如主機資訊和日誌) 儲存在 RAID 0+1 或 RAID
N
磁碟上。如果您有許多寫入,RAIDN
可能會是一個問題,因為更新同位元位元需要時間。您也可以設定資料庫使用的檔案系統的參數
如果您不需要知道上次存取檔案的時間 (這在資料庫伺服器上不是很有用),您可以使用
-o noatime
選項來掛載您的檔案系統。這會略過對檔案系統上 inode 中上次存取時間的更新,從而避免一些磁碟搜尋。在許多作業系統中,您可以透過掛載時使用
-o async
選項,將檔案系統設定為非同步更新。如果您的電腦相當穩定,這應該可以在不犧牲太多可靠性的情況下,提供更好的效能。(此標誌在 Linux 上預設為開啟。)
在考慮是否將 NFS 與 MySQL 搭配使用時,您應該謹慎。潛在的問題(因作業系統和 NFS 版本而異)包括以下幾點:
放置在 NFS 卷冊上的 MySQL 資料和日誌檔案可能會被鎖定而無法使用。當多個 MySQL 實例存取相同的資料目錄,或因停電等原因導致 MySQL 未正確關閉時,可能會發生鎖定問題。NFS 第 4 版透過引入諮詢式鎖定和基於租約的鎖定,解決了底層的鎖定問題。然而,不建議在多個 MySQL 實例之間共享資料目錄。
由於訊息接收順序錯誤或網路流量遺失而導致的資料不一致。為了避免此問題,請使用 TCP 以及
hard
和intr
掛載選項。檔案大小限制。NFS 第 2 版用戶端只能存取檔案的最低 2GB(帶號 32 位元偏移)。NFS 第 3 版用戶端支援更大的檔案(最高 64 位元偏移)。最大支援的檔案大小也取決於 NFS 伺服器的本地檔案系統。
在專業的 SAN 環境或其他儲存系統中使用 NFS,通常比在這種環境之外使用 NFS 更可靠。然而,SAN 環境中的 NFS 可能比直接連接或匯流排連接的非旋轉儲存裝置慢。
如果您選擇使用 NFS,建議使用 NFS 第 4 版或更高版本,並在部署到生產環境之前徹底測試您的 NFS 設定。