第九回 不用錢的最貴，MYSQL 到底是怎樣的資料庫

上週去協助某物流公司幫忙建置上次有問題的MYSQL的 Replication ，之前客戶出了個題目，200GB 的資料必須在 30分鐘內 Copy 完成，我們自己在公司建了環境模擬的結果，以 1000BaseT 的狀態能夠全速跑的話，有這個可能能夠完成，而且緩衝時間有 2 個小時，因此就做了(原本我要求光複製資料就要三個小時)。

誰知時間己經被卡的夠緊了的狀態下，客戶當天還排了一個 SAN Switch 更改串接設定，還有其他廠商也會一起進行的工作。還好我 SAN Switch 更改設定的工作在 40分鐘內就完成了，所以就等 MYSQL 的 Application 能夠停機的時候。

原本我要預先檢查機器，這下子才發現客戶把 Replication Target 搬去別的位置，要等客戶弄完才能做確認機器的動作，我只好先等。等到真正能上工的時間，就是原訂的工作時間了，這時我才開始確認機器設備，才發現客戶將網路連在 100Mbps 的網路上，這時才要求網路修改，等到最後 Ready ，己經超過我要做事的時間一個小時，因此整個進度也 Delay 了一個小時。

反正整個過程就是相當不順就是了，後來因為種種問題，這次好不容易安排的三個小時停機時間就這樣浪費掉了，所以 MYSQL Replication 也沒建立起來，事實上，我也不願意這種事情發生，明明我要的時間是三個小時，硬是要壓縮我的工時，而且還有一堆外力來干擾。

最後資料庫不得己要啟動時，我卻一直啟動不了，此時心裏一陣冷風吹過，這個資料庫從來沒備份成功過，如果這下子壞了，今天只有我動過，我在 IT 產業的日子大概就這樣完結了，只好一直 Try ，改參數啊，看 Log 什麼都試，後來好不容易開了起來。這時凌晨4點多被我叫起床的經理也趕來了。還好我有將資料庫開起來，不然還不知怎麼辦哩.....

只是當應用程式要啟動 Access DB 時，一直有些靈異現象發生，就是 Table 會被 Lock 住，但過沒多久就自己解開了，一直到我去檢視 Redhat Cluster 的狀態時，才發現兩個 Node MYSQL 程式都在運作。

就我一般對資料庫的認識的話，同一檔案有程序在上面時，資料庫程式應該要做一些控制，不管是誰家的，誰知道 MYSQL 並不會，所以當兩台機器都可以存取到同一個磁區時，這個磁區內的檔案居然可以被兩台機器同時存取。

所以我一直開不起來，還有應用程式連線時的怪異現象，這時就得到解釋了，說實在的，如果你的 MYSQL 要用來做交易，又像我這個客戶一年連 30 分鐘都不肯讓我關機的話，還是多花點錢吧，用個 SQL Server 也好，不要因為要省成本，搞的到時你都沒備份，資料全毀時，你就知道什麼叫做不用錢的最貴了。

基本上 MYSQL 目前的 Online Backup 的 Solution 大概都是透過 LVM 的 Snapshoot 後，再將 image 備份下來，但是在這個客戶下，因為用了 Redhat Cluster ，要做 Snapshoot 的話，在 GFS 這種 Filesystem 也有困難，因此也是沒辦法做。另外因為目前 MYSQL 己經被 Oracle 收購了，因此 Oracle 在做異質性平台資料轉換用的工具 Oracle Golden Gate在未來也會支援 MYSQL ，這個報價可能比 MYSQL 本身還貴上天的工具，我想他的可靠性鐵定是比 MYSQL 自己的 Replication 要高。