《瑪莉亞的凝望》第三本看到一半,到 Twitter 上看到 Jeremy Zawodny (O'Reilly 出的 High Performance MySQL 第一版與第二版的作者之一) 在喊 MySQL ALTER TABLE 跑了八天了:
I have an ALTER TABLE running for nearly 8 days now... yikes.
結果 Aaron Brazell 居然很機車的這樣問他 XDDD
@jzawodn Removing South Carolina from all Craigslist tables?
如果不清楚 Craigslist 與南卡的新聞,可以參考紐約時報「Under Pressure, Craigslist to Remove ‘Erotic’ Ads」這篇的說明。
Anyway,Jeremy Zawodny 有說明這次的目的是要把舊的 InnoDB 轉成 XtraDB compression 格式:
the big ALTER TABLE is to enable InnoDB/XtraDB compression on ~650M records (old CL postings)
簡單提一下 MySQL 搭配一些 open source solution 的運作方式。
首先是要打開 replication,有 master 與 slave server(s)。寫入都到 master,讀取到 slave。(這邊為了說明方便,暫時不考慮 replication delay)
除了 master/slave 讓前端的 application servers 或 web servers 存取外,另外建立一套 slave server,上面有 snapshot filesystem (像是 Linux 的 LVM,或是效能較好的 Solaris/OpenSolaris 的 ZFS),用 cron 定時將 MySQL 暫停並寫入磁碟,產生 snapshot。
在這樣的架構下,當需要 ALTER TABLE 而且已經知道會卡很久時,我們可以從 snapshot 上先複製一份完整的資料,建立一台 MySQL server 並且在上面 ALTER,等到完成後再接回 master server,將 replication delay 的部份補上。如果想確認資料正確性,可以跑 mk-table-checksum 確認。當 replication delay 跟上後,停機時間不用太長就可以將 master 換成這份新的格式。
雖然 Jeremy Zawodny 沒有詳細說明,不過應該是類似的方法。
Update:Jeremy Zawodny 在「The Big ALTER TABLE Test」這篇有提到結果。