MySQL (MyISAM) 的備份

當系統小的時候,用 mysqldump 在離峰時間把資料 dump 出來還算可行。
雖然 Table 會暫時 Lock 住,但是因為小,所以速度可以很快,鎖住的時間可以不計。
但當系統大的時候就不能這樣做了。

好在已經有許多處理這個問題的經驗者。
解決這個問題的 Key Point 是「減少鎖 Table 的時間」,因此如果採用的 File System 或是 Volume Manager 有支援快速的 snapshot 功能的話,整個問題就簡單很多。步驟如以下所示:

  1. SLAVE STOP;
  2. FLUSH TABLE WITH READ LOCK;
  3. 作 snapshot
  4. UNLOCK TABLES;
  5. SLAVE START;

如果採用 LVM (Linux), ZFS (FreeBSD, Solaris) 或是 NetApp 的話,整個備份過程可以小於 5 秒鐘,因此可以做到每個小時備份一次而不影響正常使用。如果在 Slave 上做 snapshot 備份,則完全不會影響到寫入(READ LOCK時還是可以讀)。

MySQL 在 Mtron SSD 上的測試

這次PIXNET進了2顆 32G Mtron MSP-SATA70(Spec 上寫的寫入速度為 90MB/s,讀取速度為 120MB/s),裝在 8-way、12G RAM 的 Debian Linux 上,跑 MySQL 5.1 Slave,用 MyISAM 當 backend。最大的 MyISAM Table 大概有 3GB。

這次一開始就採用 RAID 0, 4KB stripe size + XFS (4 KB Data Size) + noop disk scheduler。測試開始時,從DB Master複製資料所需的時間,大概是兩顆 SCSI 10k RPM + XFS 的 1/3,約 70MB/s。接著 replication qps 大概在 3000-4000 左右徘徊,最高大約是 15000 qps。

實際使用上(同時有 SELECT 與 UPDATE),大概 8000 qps 是極限,接著就會遇到 CPU Bound,對於較複雜的 SQL Query (SELECT … IF EXISTS)會開始卡。如果只計算單純的 SELECT QUERY,則可以到約 15000 qps。

MySQL 在創見 SSD 上的測試

看了 Kevin Burton 的文章 , PIXNET 決定找目前市場上買的到的 SSD 來測試跑 MySQL,後來是進了4顆 創見32GB MLC SSD,裝在 8-way、12G RAM 的 Debian Linux 上,跑 MySQL 5.1 Slave,用 MyISAM 當 backend。最大的 MyISAM Table 大概有 3GB。

一開始我們用 64KB stripe size 跑 RAID0,但是就如 DK 說的慘不忍睹,用 XFS 每秒的 replication qps 大概在 5~20 上下徘徊,改用 EXT3 也沒有長進,關掉 disk scheduler 也沒用,於是我們試著改 stripe size 到 4KB,不過也沒有顯著增加,對單一大 Table 的 qps 還是只有 5~20,不過若是對小一點的 Table 倒是可以到 300 左右。後來我們想繼續降低 stripe size,但發現不管是 LVM 還是 md(4) 都只支援最低 4KB。

最後發現,這顆創見 SSD 只支援到 UDMA Mode 4,而且規格裡面寫 random write 只有大概 1.6MB/s,但是平常我們的 replication write 就大概要 3MB/s,peak 到 11MB/s(XFS),而創見 SLC 的 SSD 大概也只支援到 4MB/s,還是太慢。

結論:台灣市場上目前的 SSD 效能還不夠好,而國外的 Mtron 還太貴,C/P值不夠好,兩顆 32G 就可以多加一台機器了。