前沿分享|阿里雲資料庫高階技術專家 宋利兵:阿里雲企業級自治資料庫RDS詳解

阿里雲開發者發表於2021-11-27
簡介:本篇內容為2021雲棲大會-企業級雲原生資料庫最佳實踐論壇中,阿里雲資料庫高階技術專家 宋利兵關於“阿里雲企業級自治資料庫RDS詳解”的分享。

 title=

本文將從2方面為大家介紹企業級的自治的資料庫系統。

  • RDS MySQL 產品
  • RDS MySQL 自研核心

 title=

一、RDS MySQL 產品

1)阿里雲RDS - 雲原生自治資料庫

 title=

阿里雲RDS是國內起步最早的RDS服務,基於阿里巴巴的MySQL分支AliSQL。在阿里巴巴完成IOE目標後,阿里巴巴整個電商業務由RDS支撐。RDS的可靠性和穩定性是經過了雙十一這樣極其苛刻的現實場景的驗證的。經過十幾年的發展,除了在穩定性、效能等方面有長足的發展之外,阿里雲RDS也在堅定的向雲原生和智慧化的方向邁進,現在RDS整體架構基於雲原生K8S進行部署和管理,底層依託於阿里雲的高效能ECS和高吞吐的ESSD分散式雲端儲存,真正做到了計算和儲存的分離。基於人工智慧的技術和專家的經驗,實現DAS的 RDS自治能力。

2)RDS MySQL 產品 - 服務高可用

 title=

從產品層面看,高可用是MySQL生態裡經典的架構,通過binlog進行復制,RDS提供跨可用區的高可用,可以做到4個9的可用性和秒級的切換。

 title=

除了經典的兩節點架構,RDS還基於多數派協議提供了三節點高可架構。在三節點高可用架構中,包括主和備兩個資料節點和一個日誌節點,讓使用者的資料0丟失做到RPO等於0。這個複製不是用MySQL原生binlog複製,而是採用自己實現的多數派協議(Consensuse)進行binlog的分發。

 title=

除了熱備、RDS也提供了冷備的能力。RDS可以週期性做全量資料備份、以及實時binlog的備份,並把資料上傳到OSS上。如果有資料恢復需求時,可以快速通過OSS進行資料恢復。

3)RDS MySQL 產品 – 資源池化和雲原生

 title=

在計算與儲存分離的架構下,RDS例項可以提供高達32TiB的儲存量。全量資料備份採用的是快照的方式進行的,無論使用者資料有多大,都可以做到秒級備份,真正做到使用者無感。基於秒級的資料快照能力,RDS做到了分鐘級的例項建立。建立只讀例項大概在兩三分鐘就可以完成。

4)RDS MySQL 產品 – 自動讀寫分離

 title=

只讀節點是MySQL裡經典的架構,通過建立只讀例項擴充套件讀的能力,阿里雲的RDS上提供中間介讓使用者應用不做修改自動實現讀寫分離。提供多地址的讀寫分離可以把不同的業務用不同的地址訪問,好處是業務之間不會互相影響和地址的隔離效能非常好。

5)RDS MySQL 產品 – 企業級資料安全

 title=

現在安全越來越被重視,雲上有很多使用者有合規、審計等需求,RDS為使用者提供了全鏈路加密的能力、以及審計日誌等安全能力,除此之外,使用者還能享受到阿里雲網路層面和作業系統層面的安全設施。從整體看,可以做事前、事中、事後非常嚴格的安全合規要求。

6)RDS MySQL 產品 - 整體架構

 title=

RDS不只有MySQL的核心還有很多模組一起為使用者服務,使用者只需通過控制檯進行控制,或者通過OpenAPI來建立或者管理例項就可以了,剩下的工作由RDS自動完成。

二、RDS MySQL 自研核心

1)實用性:線上固化SQL執行計劃

 title=

線上上使用RDS的時候會使用者會遇到SQL特別慢的情況,因為一些原因SQL可能沒有選擇到最優執行計劃,MySQL提供hint的功能,使用者可以在SQL語句里加hint來提示MySQL是否要使用索引,或者是否開啟某一項優化器的策略。通過Hint來提高SQL的執行效率。 為什麼這個功能使用者用得很少?因為當發現SQL慢的時候,應用已經線上執行了。這時修改應用裡的SQL、可能需要一個漫長的過程、甚至不可能修改。SQL Outline讓使用者可以在RDS伺服器側為SQL語句新增Hint。只需要呼叫一個儲存過程。比如加一個Index Hint,只需在add\_index\_outline中指定這個SQL語句,以及對應的索引策略即可。在做規則匹配時,Where條件中的值會自動忽略掉,同樣的語句不同的值,都會匹配到這條規則。使用者的應用不需要做任何變化,加上規則後會立即生效,這是非常實用的功能 。

2)實用性:可診斷、可度量

 title=

我們加了大量的監控和診斷資訊,可分為例項級別、物件級別、語句級別三大類。

 title=

例項級別的指標非常多,把MySQL和系統裡的指標以秒為單位儲存到表裡去,讓使用者非常方便地通過MySQL語句查詢。包括例項的CPU使用情況、記憶體使用情況、磁碟IO情況、Server層連線數量、網路訪問情況,已經InnoDB中的大量狀態資訊。RDS把這些狀態資訊以秒為單位記錄下來,出現問題時很容易通過狀態的變化準確地定位出問題。

 title=

物件級別新增加了對錶使用和Index使用的統計,為我們做資料結構的調整提供了依據。

 title=

語句級別MySQL有一個語句級別的統計資訊表,RDS在這個表裡新增了一些非常實用的資訊。比如:語句使用CPU的時間,MDL、InnoDB鎖等待的時間,Mutex的spin、wait的統計資訊,Read/Write IO的統計資訊。這些統計項幫助使用者準快速精準的定位SQL的問題。

3)穩定性:Buffer Pool優化

 title=

雲原生下需要能夠做到線上規格的調整,Buffer Pool就是很重要的資源。當規格、記憶體變化的時候Buffer Pool也需要跟著變化,MySQL提供線上調整Buffer Pool大小的能力。在測試中,我們發現MySQL Buffer Pool Resize會對業務流量造成一定的影響。業務流量抖動的頻率和幅度都很大(綠色線條)。阿里雲RDS在Buffer Pool Resize上做了優化,優化後、Buffer Pool Resize對業務流量的影響就好了很多(藍色線條).

4)穩定性:併發控制

 title=

線上經常碰到某些SQL語句會使用大量的CPU資源或者記憶體資源。如果不做限制,可能會耗光CPU、記憶體資源,導致整個例項不穩定。併發控制這個功能可以用來限制特定SQL的併發數量。併發控制的策略可以分為三個維度:操作型別、操作物件、關鍵字。操作型別指的是SELECT、INSERT、UPDATE、DELETE四種型別。操作物件指的是庫、表。併發控制和SQL Outline差不多,都是在RDS服務側配置的。

5)安全性:透明資料加密

 title=

透明加密支援AES加密演算法和國祕演算法SM4。因為有些單位有合規要求,必須使用國密演算法。

6)安全性:回收站

 title=

回收站是表級的資料快速找回的工具。當使用者刪除表或者Truncate表的時候,表不是直接從磁碟上刪除,而是放到回收站裡。使用者可以設定多長時間後自動在後臺把表真正刪除,當發生了誤操作,錯誤的刪除或者清空了表時,能快速從回收站中找回表。

7)安全性:Flashback Query

 title=

Flashback Query提供了快速找回資料行的能力。行級資料找回的功能利用了Undo裡面的歷史資料。RDS可以以秒為單位,為歷史資料建立快照。RDS提供了基於時間的快照查詢機制,通過Undo的記錄回溯到指定時間的歷史資料。當發生了誤操作、或者有回檔需求時,使用者可以通過SELECT查詢到指定時間點的歷史資料。

8)高效能 – Binlog In Redo

 title=

MySQL在事務提交時要持久化Redo和Binlog檔案,為了保證Crash Safe兩個檔案必須順序進行持久化對效能影響很大。RDS會把Binlog同時寫到Redo裡面去,因此事務提交時,只要持久化Redo檔案。Binlog檔案只需要在後臺非同步持久化就可以了。這個功能在保證資料一致性的同時,對寫效能有顯著的提升。

 title=

上圖是這個功能的效能測試結果,有30%-40%效能峰值的提升,在小併發的情況下甚至能超過百分之百的效能提升。

9)高效能 – DDL優化

 title=

當做非Instant DDL操作的時候,往往會處理DDL表的大量的Page。MySQL通過掃描Buffer Pool的LRU連結串列來完成這個操作。LRU包含了Buffer Pool中所有的資料頁,特別是對大規格的例項,掃描一遍LRU的時間很長,還會影響其他SQL語句的執行。RDS做了優化後,DDL可以直接命中它的Page,不在需要掃描LRU。既能提高效能又能保持例項的穩定性。上圖效能測試,是在有業務流量的情況下做一次Export Table。Export Table的執行時間從原來的80秒降低到了0.34秒。

 title=

上圖是對Optimize Table的測試,在有業務流量的同時做Optimize Table,這個表有600MB資料,DDL的優化將OPTIMIZE TABLE的效能提升了十幾倍,由原來的220秒降低到了17秒時間。

10)高效能 – Faster Query Cache

 title=

我們基於MySQL的Query Cache做了重構,對併發控制、記憶體管理、快取機制都做了大量的修改,在命中率較高的情況下效能得到提升,在命中率較低的情況下對效能沒什麼影響,預設的就能開啟這個功能。

11)RDS MySQL自研核心: 企業級三節點

 title=

基於自研的多數派協議來傳輸Binlog。Leader負責把Binlog傳輸到日誌節點或者Follower節點後,到達多數派後在Leader節點上做事務提交,三節點自己選主形成自治的系統,在整個的過程中沒有資料丟失做到RTO為0。

版權宣告:本文內容由阿里雲實名註冊使用者自發貢獻,版權歸原作者所有,阿里雲開發者社群不擁有其著作權,亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容,填寫侵權投訴表單進行舉報,一經查實,本社群將立刻刪除涉嫌侵權內容。

相關文章