當系統小的時候，用 mysqldump 在離峰時間把資料 dump 出來還算可行。
雖然 Table 會暫時 Lock 住，但是因為小，所以速度可以很快，鎖住的時間可以不計。
但當系統大的時候就不能這樣做了。
好在已經有許多處理這個問題的經驗者。
解決這個問題的 Key Point 是「減少鎖 Table 的時間」，因此如果採用的 File System 或是 Volume Manager 有支援快速的 snapshot 功能的話，整個問題就簡單很多。步驟如以下所示：
如果採用 LVM (Linux), ZFS (FreeBSD, Solaris) 或是 NetApp 的話，整個備份過程可以小於 5 秒鐘，因此可以做到每個小時備份一次而不影響正常使用。如果在 Slave 上做 snapshot 備份，則完全不會影響到寫入（READ LOCK時還是可以讀）。
這次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。
看了 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 就可以多加一台機器了。