【華爲雲數據庫技術大公開】機房失火後，還能拯救你的數據嗎？

【摘要】 升級後的華爲雲GaussDB，如何用技術服人？數據存儲、遷移和容災備份，這些技術竅門你必須知道！

相信不少人都有整理C盤的經歷，C盤做爲電腦的系統盤，系統運行所需的關鍵數據都存儲在其中。但若是使用不當，C盤就特別容易變紅，而後電腦變卡，惡性循環，最差的結局就是系統崩潰，全部數據丟失。

對於企業來講，數據存儲和管理更是關乎生存的大事。

現在的企業數據量大、數據來源多樣、數據形態複雜，原有的存儲模式已經沒法知足需求，反而會加劇存儲負擔。

因此，磨刀不誤砍柴工，大家企業的數據存儲作好了嗎？巧婦難爲無米之炊，大家業務的瓶頸是否是能夠從數據存儲管理的維度打破？

打好數據存儲的地基

從最先的穿孔卡片、關係數據庫、非關係數據庫到現在的雲數據庫，Gartner研究報告稱到2023年，全球75%的數據都會出如今雲平臺上。

數據上雲四個字打出來容易，但真正落實下來卻存在各類困難。

第一重要的環節即是數據存儲，就像建高樓同樣，打好地基是關鍵，只有把數據存儲這個環節作到極致，業務才能馬不停蹄跑起來。

目前，很多雲服務廠商都推出了數據庫產品，在去IOE的路上一路狂奔。

而一個優秀的數據存儲產品，既要給足安全感，還要夠便宜，讓數據存儲再也不是負擔，而是業務的催化劑。

目前，從結構化/非結構化數據的存儲、到數據的複製遷移、災備以及預處理，華爲雲給數據上雲的每一個環節，都填滿了相應的產品。

不管什麼業務場景，均可以在短時內完成數據庫的部署，實現雲端徹底託管。

而之因此能作到又快又全又便宜，華爲雲的這些技術絕招功不可沒，且聽咱們慢慢道來。

數據庫「意外失聯」，DRS速來支招

一、不停機免費遷移

若是將數據庫比喻成「城市」，咱們能夠理解DRS（數據複製服務）即是城市之間的「地底光纖」，確保將「始發地」源庫的數據安全、快速、高效地運輸到「目的地」目標庫。

爲了保障數據庫遷移過程當中數據的一致性，一種方式是須要停掉業務，進行一次性遷移（也稱離線遷移），這就形成了數據量越大，遷移時間越長，也就意味着停機時間越久。

那麼是否有一種方式既能保障數據庫遷移過程當中數據的一致性，又能作到業務持續運行？

DRS經過全量遷移+增量同步的方式（也稱在線遷移），在全量遷移完成後，啓動增量同步過程。

增量同步是將源庫先進行日誌解析，日誌能夠很形象的當作是「錄像帶」，記錄了源庫的全部操做，咱們將日誌「回放」出來，源庫作了什麼數據操做，目標庫就作什麼樣的操做，最終這部分增量數據被並行複製到目標庫，來保證數據的一致性。整個過程能夠理解爲在業務運行的過程當中，潛移默化地完成了源庫與目標庫之間的數據遷移，業務無感知。

本來只能是數據庫遷移專家才能完成的複雜數據庫遷移現在在雲上變得輕鬆簡單，普通的從業者也能完成雲上數據庫高效遷移，極大便利了客戶、一線運維人員和開發者。

二、多活災備

但也有人會極度缺少安全，一旦數據沒有放在本身的眼皮底下，擔心老是無盡的。

在遷移上雲後，數據備份和恢復的問題一直困擾中型企業。老闆老是會擔憂，個人數據都放在大家服務器裏，哪天大家機房發生地震，個人數據怎麼辦？

首先，華爲雲數據庫很早便推出了雙AZ高可用災備方案，即「同城兩中心」，也就是在同城創建兩個數據庫，當其中一個數據庫突發異常或被破壞時，能夠從另外一個數據庫獲取數據，以保證系統的持續穩定。

華爲雲數據庫在「同城兩中心」的基礎上提出了異地保護的方案，DRS推出了異地多活災備，即「兩地四中心」。

該災備方案支持搭建主備高可用架構，當主實例所在區域突發天然災害等情況，主備節點均沒法鏈接時，可將異地災備實例切換爲主實例，便可快速恢復應用的業務訪問，並且能夠實現主實例和跨區域的災備實例之間的實時同步。

彈性擴容以外，從「快遞驛站」得到高寫入性能

華爲雲數據庫產品不得不提的一個特色就是彈性擴容，業務無感知。

以GaussDB(for MySQL)爲例，其基於華爲最新一代DFV分佈式存儲，採用計算存儲分離架構。

當計算和存儲解耦，再利用雲架構彈性的優點，存儲和計算都可單獨按需擴縮容，且在分鐘內完成，資源利用率達到最大化。

GaussDB(for MySQL)還支持1寫15讀的只讀節點的極速擴展，最高支持128TB的海量存儲，可實現超百萬級QPS吞吐，單節點相比原生MySQL性能提高7倍，並且兼容MySQL，無需分庫分表，應用無需改造便可輕鬆遷移上雲。

另外，GaussDB(for MySQL)數據庫在寫入性能上，在業界同類產品中是最好的，這主要得益於它在MySQL內核方面的諸多優化，其中有一項即是從「送快遞」得來靈感的優化——事務異步提交。

快遞的配送過程當中，最耗時的，不是裝貨、卸貨，而是電話和等待。快遞驛站能夠很大程度解決這個問題。

一樣，事務處理過程當中，存儲的IO就是一個較長的等待。

數據庫使用經驗豐富的開發人員來都知道，等待redo日誌寫入存儲的磁盤IO性能，很大程度上決定了數據庫的寫入性能。

對於GaussDB(for MySQL)這樣存算分離的數據庫，存儲的IO耗時在事務處理的總耗時中佔據不小比例，雖然有log buffer的合併寫入，提高併發狀況下的總體吞吐，但若是在等待IO時間內，這些線程可以去作別的事情（例如處理等待中的其餘事務），那麼將會有進一步的性能提高。

既然找到了等待的點，那麼咱們就能夠像快遞配送的優化方法，爲數據庫創造一個「快遞驛站」。

圖： GaussDB(for MySQL)的「快遞驛站」

如圖所示，當redo日誌的flush to disk動做完成後，便可進行事務提交，可是此時並不該答客戶端，而是直接處理下一個事務。同時使用少許post comit worker線程，來批量等待日誌寫入完成（等待的過程其實並不佔用CPU），並應答客戶端，這就可讓「等待」和「下一個事務的處理」並行化，讓CPU「閒不下來」。

在標準的sysbench寫入模型下，沒有使用Post Commit時極限性能是35萬QPS左右，而使用Post commit後能夠到大42萬以上的QPS，提高了20%的寫入性能。

擔憂事務丟失？華爲雲數據庫MySQL表示不可能

數據上雲後，企業對雲上數據庫的要求也愈來愈高，尤爲是數據的完整可靠。

有的雲廠商爲了保證事務不丟失，選擇增長一個數據庫結點的方式，但成本也相應提升。

有沒有一種一箭雙鵰的方法，既能保證數據零丟失，還能下降成本？

華爲雲數據庫MySQL高可靠的應用機制能夠作到：主備模式下，在最大程度保證主庫效率的同時，保證主庫崩潰時快速恢復服務，而且作到事務零丟失，進而保證企業業務的穩定持續。

華爲雲數據庫MySQL半同步複製基於狀態通道和時間戳的高可靠特性，整體上是管控節點（HA）保存主庫最後的複製狀態和時間戳，備實例保存主庫最後的複製狀態和時間戳，而後經過比較它們來精準判斷主庫崩潰時的複製狀態。

在自行恢復方面，它能夠根據主庫崩潰時的複製狀態按照如下四種狀況準確恢復服務，保證不丟失事務，而且秒級恢復服務：

• 在同步複製狀態下主庫崩潰，拉起主庫；
• 在同步複製狀態下主庫崩潰，若是不能拉起主庫，服務平滑切換到備庫；
• 在異步複製狀態下主庫崩潰，不能切換到備庫，拉起主庫；
• 在異步複製狀態下主庫崩潰後，不能切換到備庫，若是不能拉起主庫，會在原來的數據上恢復主庫。

華爲雲數據庫MySQL半同步複製高可靠特性能最大程度保證主庫效率，是由於主庫的事務提交只依賴於備庫，而備庫把這個事務寫入中繼日誌後當即返回一個ACK（即確認字符），沒有強同步複製備庫回放事務帶來的延遲。

舉個例子，若是用戶買了華爲雲數據庫MySQL，當半同步複製主庫正在執行大事務，而且複製狀態從同步複製轉換到異步複製時，主庫忽然掛掉，用戶服務被迫中斷，華爲雲數據庫MySQL主庫會在秒級內被拉起對外提供服務，用戶能夠從新鏈接上華爲雲數據庫，而且與中斷前的數據視圖徹底一致，沒有事務丟失。

最後：

水是萬物之源，數據就是互聯網之源。做爲計算機的三駕馬車之一，數據庫是承載互聯網之源的關鍵。

828企業上雲節期間，華爲雲的數據存儲產品也推出了優惠活動，正是企業入手雲數據庫的最佳時機。

若是要存儲處理結構化數據，有云數據庫 MySQL、雲數據庫 PostgreSQL和GaussDB（for MySQL）；

若是是非結構化數據，有OBS對象存儲服務、文檔數據庫DDS以及MapReduce服務，還有Redis、Kafka等中間件，從數據存儲、數據入湖、災備到分析，不管什麼業務場景，總有一款產品最適合你。

點擊關注，第一時間瞭解華爲雲新鮮技術~