從本地MySQL遷移到雲資料庫，為什麼是Amazon Aurora？

　　近兩年，隨著雲環境的成熟，很多企業的業務都在向雲端遷移。於是，“雲資料庫”成為最時髦詞彙之一，被AWS、微軟、阿里、華為等大廠推崇。那麼，對於使用者來說，他們如何看待雲資料庫的發展現狀，到底哪些因素才是他們選型的關鍵點？老王的經歷，或許能從一定程度上說明中國雲資料庫發展現狀。

　　老王的心路歷程

　　A網站，是國內大型社交媒體之一，老王是這家網站的DBA。像很多人說的一樣，好的架構從來都不是設計出來的，而是演進出來的，資料庫也是如此。從商業資料庫到開源資料庫，再到雲資料庫，老王是資料庫變革的最直接見證者和推動者。

　　起初，A網站日活躍使用者達到1.5個億。使用者註冊時，需要給每一個使用者分配獨立的ID，並儲存使用者名稱、密碼、出生日期、單位等資訊。另外，登入後要對訊息、關注、查詢、評論、轉發等進行管理。這家網站的資料庫採用的是標準結構，按照讀寫分離設計，主庫承擔寫，從庫承擔訪問，如果訪問壓力過大，就透過擴容從庫的數量獲得擴充套件能力。並且，所有業務按照使用者、內容和關係進行垂直劃分，使用單獨的資料庫。

　　之後，隨著移動網際網路的快速發展，A網站註冊使用者數也跟著瘋漲，原有的資料庫呈現前所未有的壓力。為了支援業務高速發展需求，只能採購效能更好的硬體裝置，對各功能模組分別獨立儲存，並對海量業務資料進行二次拆分。由於沒有時間進行架構改造，只能透過購買硬體裝置來支撐核心業務。那時，feed系統重度依賴MySQL，最高併發的時候，MySQL寫入QPS飈到過4W。由於資料庫效能問題，直接導致網站癱瘓，使用者流失，當時的場景，老王至今記憶猶新。為了保障查詢的效能指標，老王及其團隊成員對索引和內容進行了拆分，各自分了很多埠，每個埠分出了很多的DB。

　　經過改造後的資料庫，已經逐步趨於穩定，但是當峰值出現的時候，MySQL依然有查詢慢的問題。並且，對於運維人員來說，運營維護不夠自動化。為了解決這些問題，老王開始研究雲端遷移的問題。

　 　自建雲端MySQL，還是選擇成熟的雲資料庫？

　　為了保持資料的一致性，老王最開始考慮的是在雲伺服器上自建MySQL資料庫。

　　畢竟MySQL是一個有著20多年曆史的開源資料庫，也是最流行的網際網路開源資料庫。尤其是MySQL升級到MySQL 8.0後，已經做了很多最佳化，有很多新特徵。比如：支援了json的資料型別，實現了json資料型別的讀取和訪問，支援NoSQL介面等。

　　自建雲端MySQL，便擁有了雲的特徵，包括：高可用，可彈性擴充套件，可簡化運維等。但是，自建雲端MySQL的弊端也非常明顯：首先，雲伺服器成本太高，需要做軟、硬體的配置。其次，自建資料庫需要DBA自己來維護，安全性很難保證。尤其是由硬體故障導致的安全隱患，很難控制。還有，DBA的水平問題，也決定了資料庫的穩定性。其三，部署週期太長，需要採購硬體，找機房託管，重新部署。對於老王來說，他們沒有更多的人力、物力來解決這些問題。自建雲端MySQL，無異於在給自己“挖坑”。

　　所以，老王決定還是直接選用成熟的解決方案。於是，“雲資料庫”跳入他的眼簾。

　　放眼望去，市場上可選的“雲資料庫”有很多。包括：AWS的Amazon Aurora，阿里的PolarDB、華為的雲資料庫MySQL等。如何去選型?

　　老王綜合評估了下，認為有幾點很重要：

　　第一，必須選擇大品牌。A網站是大型社交網站，資料庫就是企業的全部價值，老王不能拿網站的命運和自己的職業生涯做賭注。所以，雲資料庫產品必須位列前三。而AWS是全世界第一大雲端計算提供商，佔據了大部分市場份額。

　　第二，必須選擇成熟的解決方案。選擇把資料庫遷移到雲端，就是為了獲得更好的效能，但是更高的效能要是以可靠性為代價，老王寧願保持現狀。況且，雲資料庫在中國畢竟是一個新概念，如果沒有成熟的案例，老王不能去當這個“小白鼠”。從這點考慮， Amazon Aurora無疑最佔優勢。Amazon Aurora釋出於2015年，經過三年的驗證，已經得到了Autodesk、TIBCO、亞利桑那州立大學、通用電氣、BMC、每日新聞等諸多客戶的肯定。

　　第三，要在具備更高效能的基礎上，相容MySQL。Aurora的效能，毋庸置疑，作為雲資料庫領域的頂級代表作，其吞吐能力無人能及。很多資料庫產品都把Aurora當做標杆，參考Aurora的架構去做。另外，做資料庫最大的挑戰就是相容性。如果相容性差，會讓遷移成本高出很多倍，這也是為什麼說中介軟體和分庫分表是反人類方案的根本原因。Aurora恰好具備相容性特點，完全可以覆蓋MySQL和PostgreSQL。

　　第四，可託管。老王希望使用雲資料庫以後，可以減輕資料庫維護壓力。無需擔心硬體、軟體補丁、設定、配置或備份等資料庫管理任務。並且，雲資料庫解決方案能提供自動監控功能，能夠自動持續監控並將其備份到儲存服務中，可以實現更精細的時間點恢復。在這一點上，Amazon Aurora也完勝同類解決方案。

　　第五，在資料庫遷移過程中，不能影響業務執行。Amazon Aurora能快速啟動，可直接連線到源資料庫和目標資料庫，能把停機時間縮到最短。使用者可透過AWS DMS 建立表、載入資料並使其保持同步，隨時將應用程式切換到目標。

　　如何遷移?

　　從本地MySQL到雲Amazon Aurora，老王是如何遷移的呢?

　　從Amazon官網的遷移手冊來看，Amazon Aurora有多種不同的遷移方法。A網站選擇的是Percona XtraBackup備份工具，能支援全備及增量備份等。對比MySQLdump，XtraBackup 備份的是資料庫的二進位制資料及日誌，並且檔案可壓縮得更小。這樣，無論是備份和還原，速度都更快。

　　安裝完備份工具後，再備份MySQL資料庫，然後將備份 MySQL 檔案上傳到 Amazon S3。最後，在 Aurora Console 中還原備份檔案到 Amazon Aurora。

　 　資料庫例項和例項監控

    為了進一步最佳化成本並滿足多個應用程式的額外要求，A網站執行了以下步驟：

　　1，根據 CPU 利用率自動調整 Aurora 副本的數量。不再持續執行多個副本，僅在需要時增加副本。

　　2，為所有叢集部署Aurora快照工具，從而自動複製快照並實施30天的快照保留規則。使用控制檯操作快照注入，Binlog複製的只讀副本，DMS也可以訪問資料庫，並設定為源或者目標。

　　3，採用全量MySQLdump加增量Replication方式。但是，在 MySQLdump 匯出資料並複製到目標資料庫這段時間內，主庫要設定為只讀，避免新資料寫入。

　　4，啟用 CloudWatch Logs，建立 CloudWatch 指標和警報，從而持續監控 Aurora 資料庫叢集中的活動。

　　5，在決定遷移前，要做相容性測試。我們可以定義Aurora的Master節點容量大小，臨時測試環境可以使用t系列的機型，生產環境可以使用r系列的機型。可根據生產的壓力選擇合適大小的機型。

　　最終，A網站非常成功地把MySQL上的資料遷移到了Amazon Aurora。綜合來看，在效能上高於原來的5倍，的確不只是傳說。Amazon Aurora大大提高了原有資料庫的效能和可擴充套件性，並且最佳化了成本。在峰值期間，系統能收到高於原來至少10倍的請求。

　　 效能表現

    自此，老王終於可以鬆一口氣了。未來，他想把更多的關注點放在更有價值的業務上，而不是每天被各種紛繁複雜的瑣事，忙得焦頭爛額。

　　寫在最後：

　　Amazon Aurora，一個最有魅力的極光女神，創造了全球雲資料庫之最。對於中國使用者來說，很多人可能不懷疑他的技術能力，但是對於本地服務是否給力，心存疑慮。其實，AWS早已在佈局中國市場，由光環新網運營的AWS中國(北京)區域和西雲資料運營的中國(寧夏)區域提供與全球各地的其他 AWS 區域相似的技術服務平臺。開發人員可以在中國境內輕鬆、高效地部署基於雲的應用程式，使用相同的 API、協議和與 AWS 全球客戶無差別的操作標準。

　　如今，AWS正在向中國使用者大力推廣Amazon Aurora，如果您想體驗雲資料庫帶來的極致體驗，點選這裡即可 申請AWS 中國區域賬戶 >>