標籤:
公司採用的是ucloud的雲主機,資料庫也是架設在雲主機上。由於資料越來越多資料查詢資料越來越慢,所以我決定往 UDB上遷移。當時考慮的理由如下:
(1)雲主機底層架設在虛擬機器上IO效能有折損,而UDB底層直接就是物理機叢集IO效能有保障。
(2)UDB便於維護,直接就能查看各項效能指標及當前即時狀態。
(3)方便的主從設定和擴充伸縮,主庫配置好後,設定從庫點兩下滑鼠就搞定,而且能隨時改變更配置置滿足不同時段的效能要求。
事實證明我還是太年輕了。
遷移步驟,
(1) 配置UDB主庫
主庫主要負責寫入資料,所以配置的比較低,為1.5G記憶體100G儲存
(2) 匯出雲主機mysql主要資料庫
採用mysqldump命令匯出資料,匯出檔案sql檔案大小為3G,耗時幾分鐘。
(4) 匯入UDB
採用sourse命令匯入,匯入耗時2個小時多。(這時我就開始擔心效能問題)
(5) 測試UDB主庫
測試結果很不理想UDB的效能比雲主機滿了幾倍,這個結果不科學。
(6)建立UDB從庫
配置為3G記憶體100G儲存
測試步驟
執行同樣的sql語句進行對比
180萬資料單表 全表掃描查詢
UDB 5分11秒
雲主機 28秒
難道是UDB配置過低問題?
看看udb的狀態
都很正常沒啥問題,為啥那麼慢呢?升級到3G記憶體
再試試 表關聯刪除資料
最長的執行時間為4分鐘
而在雲主機上最長執行時間為25秒
再查看UDB狀態發現有幾條慢查詢的執行。
那就查看一下慢查詢的日誌。
mysql> system vim /opt/udb/instance/mysql-5.6/udb-jpcbmd/log/mysql-slow.log
我擦 查不到
跟客服一聊才知道 不能這麼查
那就 執行語句查詢 結果
我勒個去 刷屏了,那我匯出成文字檔 總可以吧
這都不行,原本以為營運方便呢,差個日誌都那麼費勁。
又跟客服 扯了半天,把情況反映,客服又去找UDB的工程師查看原因
結果給的是
貌似跟我現在的情況也沒啥毛關係 我就執行一條語句 一個線程 你給我看這個。
最後還是人家UDB的工程師牛叉,給出了最終解釋。
原來是對硬碟的iops做了限制,那問問限制與配置的對應關係,好選配置。
問了等於白問,
遷移也不遷移了,還用原來的雲主機吧。多建幾個從庫吧。
SSD UDB的應該效能不錯,沒去對比測試
失敗的資料庫遷移UDB