1、深入探索兼容MySQL的Amazon Aurora方案AWS 數(shù)據(jù)庫服務(wù)專為滿足您的所有應(yīng)用程序需求而構(gòu)建DynamoDBNeptuneRDSAuroraCommunity CommercialTimestreamQLDBElastiCache關(guān)系鍵 - 值文檔內(nèi)存圖時間序列分類賬DocumentDBAmazon Aurora與 MySQL 和 PostgreSQL 兼容的關(guān)系數(shù)據(jù)庫，專為云而打造 性能和可用性與商業(yè)數(shù)據(jù)庫相當，成本只有其 1/10高可用性和持久性容錯、自我修復(fù)能力的存儲; 跨 3 個可用區(qū)復(fù)制 6 份數(shù)據(jù); 持續(xù)備份到 S3完全托管由RDS托管: 無需擔心硬件預(yù)置、 軟件修補

2、、設(shè)置、配置或備份高度安全網(wǎng)絡(luò)隔離,動/靜態(tài)數(shù)據(jù)加密高性能和可擴展性5 倍標準 MySQL 的吞吐量、 3 倍標準 PostgreSQL 的吞吐量; 可擴展多達15個只讀副本Aurora客戶采用情況AWS有史以來增長速度最快的服務(wù)在前百大AWS客戶當中，有四分之三選擇使用Aurora性能存儲應(yīng)用程序應(yīng)用程序應(yīng)用程序SQL事務(wù)緩存日志記錄SQL事務(wù)緩存日志記錄SQL事務(wù)緩存日志記錄SQL事務(wù)緩存日志記錄SQL事務(wù)緩存日志記錄SQL事務(wù)緩存日志記錄存儲存儲存儲存儲相同的整體式堆棧分布式共識算法表現(xiàn)不佳傳統(tǒng)分布式數(shù)據(jù)庫堆棧Amazon Aurora: 橫向擴展、分布式架構(gòu)MasterReplicaR

3、eplicaReplica主共享存儲卷副副SQL事務(wù)緩存SQL事務(wù)緩存SQL事務(wù)緩存不再需要妥協(xié)！AZ1AZ2AZ3寫入性能讀取橫向擴展可用區(qū)+1容錯機制即時數(shù)據(jù)庫重做恢復(fù)將Log機制推送至存儲層4/6寫入仲裁與本地跟蹤二進制日志數(shù)據(jù)雙寫入日志FRM文件寫入類型MYSQL副節(jié)點EBS鏡像EBS鏡像AZ 1AZ 2Amazon EBS主實例副實例1Amazon ElasticBlock Store (EBS)2345AZ 1AZ 3主實例AZ 2副實例同步4/6仲裁分布式寫入副實例Amazon S3AMAZON AURORAMySQL I/O配置運行Sysbench 30分鐘780K個事務(wù)每事務(wù)

4、7.4次I/O27,378K個事務(wù) 每事務(wù)0.95次I/O達到前者的35倍 僅為前者的1/7.7Aurora IO配置運行Sysbench 30分鐘Amazon S3MySQL 與 Amazon Aurora 的I/O配置差異A u r o r a 存儲節(jié)點的I / O 處理Primary InstanceINCOMING QUEUESTORAGE NODES3 BACKUP12345678UPDATE QUEUELOG RECORDSACKHOTLOGDATA BLOCKSPOINT IN TIME SNAPSHOTGCSCRUBCOALESCESORT GROUPPEER TO PEER

5、GOSSIPPeer Storage Nodes所有步驟都是異步的僅有步驟1與2處于前臺延時過程中 輸入隊列比MySQL少46倍有利于延時敏感型操作使用磁盤空間緩沖活動中的峰值實際運行效果IO 流 接收記錄并添加到內(nèi)存隊列中 持久化日志記錄并確認 組織日志記錄并鑒別日志中的縫隙 通過Gossip協(xié)議填補對等節(jié)點中縫隙 將日志記錄合并到新版本的數(shù)據(jù)塊中 定期將日志和新塊中轉(zhuǎn)到S3 定期垃圾回收舊塊 定期對塊進行CRC校驗寫入與讀取吞吐量AuroraMySQL 的速度可達MySQL的5倍050,000100,000150,000200,000250,000MySQL 8.0MySQL 5.6Aur

6、ora 5.60100,000200,000300,000400,000500,000600,000700,000800,000MySQL 8.0MySQL 5.6Aurora 5.6MySQL 5.7Aurora 5.7MySQL 5.7Aurora 5.7寫入吞吐量讀取吞吐量在R4.16XL實例上運行Sysbench處理250份表，每份表包含20萬行負載條件下的性能變化1210864200600100200300400500時間以秒為單位SysBench OLTP（只寫）工作負載與250張表，每表20萬行，采用R4.16XL實例Amazon Aurora 一致性提升200倍寫入響應(yīng)時間（秒

7、）Amazon Aurora MySQL 5.6 on EBS數(shù)據(jù)加載數(shù)據(jù)加載索引構(gòu)建索引構(gòu)建0100200300500600700800MySQLAmazon Aurora400運行時間（秒）10張Sysbench表，每張表10M行，采用R4.16XL實例批量數(shù)據(jù)加載性能A u r o r a M yS Q L 數(shù)據(jù)加載速度相當于M yS Q L 的2 . 5 倍頁面緩存更新Aurora 主節(jié)點30% 讀取70% 寫入Aurora副節(jié)點100% 新讀取共享多可用區(qū)存儲MySQL 主節(jié)點30% 讀取70% 寫入MySQL副節(jié)點30% 讀取70% 寫入單線程二進制日志數(shù)據(jù)卷數(shù)據(jù)卷讀取橫向擴展使用

8、完整的變更邏輯相同的寫入工作負載獨立存儲以物理方式使用delta變更不向副節(jié)點寫入共享存儲MYSQL 讀取擴展AMAZON AURORA 讀取擴展“在MySQL當中，我們看到復(fù)制延遲達到近12分鐘。從實際應(yīng)用的角度來 看，這顯然是種近乎荒謬的情況。利用Aurora，4個副本的最大讀取延遲從 未超過20毫秒?！盉inlog Replica Lag (sec.)Aurora物理復(fù)制延遲（毫秒）Aurora邏輯復(fù)制延遲（秒）Amazon AuroraMySQL 邏輯與物理復(fù)制延遲SysBench OLTP(只寫)10 GiB工作負載，250份表，每表20萬行不再被迫妥協(xié)！恢復(fù)時間與寫入性能并行、分布

9、式處理讓處理更接近數(shù)據(jù)減少緩沖池污染數(shù)據(jù)庫節(jié)點存儲節(jié)點下推預(yù)測聚合結(jié)果降低查詢延遲并行查詢眾所周知的決策支持基準我們對Aurora的并行查詢功能進行了測試，并發(fā)現(xiàn)性能提升效果非常顯著。具體來說，我們得以將實例類型從r3.8xlarge降低至r3.2xlarge。對于這一用例，并行查詢代表著巨大的性能進步。云數(shù)據(jù)架構(gòu)師Jyoti Shandil20 x0 x40 x60 x80 x120 x100 xQ1Q2Q3Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22減少查詢響應(yīng)時間峰值加速約120倍超過10倍加速

10、：22項查詢中的8項并行查詢性能結(jié)果并行查詢性能結(jié)果可用性與持久性“可用區(qū)+1”容錯機制為什么？在大規(guī)模集群體系中，故障總會出現(xiàn)可用區(qū)故障是一種“命中注定”AZ 1AZ 2AZ 3可用區(qū) 故障時的 仲裁中斷2/3讀取2/3 寫入AZ 1AZ 2AZ 3可用區(qū)故障 時仲裁仍可 繼續(xù)起效3/6讀取4/6寫入如何實現(xiàn)？6份副本，每可用區(qū)2份2/3仲裁無法滿足需求持續(xù)備份并行保存每個分區(qū)的定期快照，將重做日志引流至Amazon S3持續(xù)執(zhí)行備份，且不影響性能或可用性水平在還原時，將對應(yīng)的分區(qū)快照與日志流檢索至存儲節(jié)點將日志流應(yīng)用于并行與異步分區(qū)快照分區(qū)快照日志記錄恢復(fù)點分區(qū)1分區(qū)2 分區(qū)3時間數(shù)據(jù)庫回

11、溯從意外DML或DDL操作中回溯回溯不具有破壞性，您可以多次回溯以找尋正確的時間點t0t1t2t0t1t2t3回溯機制代表將數(shù)據(jù)庫恢復(fù)至某一時間點，而無需使用備份資源t4t3t4回溯至t1回溯至t3不可見不可見即時崩潰重做恢復(fù)傳統(tǒng)數(shù)據(jù)庫重放自上次檢查點之后的日志在單線程中慢速重放檢查點數(shù)據(jù)重做日志在T0上發(fā)生的崩潰，需要重 新應(yīng)用自上一次檢查點保存 后重做日志中的SQLT0T0AmazonAurora無需檢查點無需重放啟動準備在T0上發(fā)生崩潰后，重做日志能夠以并行、異 步方式按需應(yīng)用于各個分區(qū)在多可用區(qū)內(nèi)最多可提供15份可升級的只讀副本 副節(jié)點與主節(jié)點共享存儲不丟失數(shù)據(jù)可配置故障轉(zhuǎn)移順序主節(jié)點

12、讀取副節(jié)點讀取副節(jié)點讀取副節(jié)點共享分布式存儲卷讀取副節(jié)點與快速故障轉(zhuǎn)移全局復(fù)制更快的災(zāi)難恢復(fù)速度與數(shù)據(jù)位置強化AuroraGlobalDatabase針對全球分布式應(yīng)用程序而設(shè)計的高性能數(shù)據(jù)庫單個 Amazon Aurora 數(shù)據(jù)庫跨越多個 AWS 區(qū)域基于存儲的復(fù)制，典型延遲小于 1 秒不會影響數(shù)據(jù)庫的性能寫主節(jié)點在一個區(qū)域，讀副本在其它區(qū)域跨區(qū)域災(zāi)難恢復(fù)為全球化應(yīng)用提供低延遲的快速本地數(shù)據(jù)讀取主區(qū)域從區(qū)域應(yīng)用程序存儲存儲復(fù)制延時 1s可管理性性能洞察能力儀表板顯示數(shù)據(jù)庫負載操作簡單支持拖放等直觀操作強大 可通過放大進行深入觀察 確定性能瓶頸來源按首要SQL分類按主機、用戶、等待事件等分類

13、可調(diào)節(jié)時間范圍小時、天、周、月最高保留近2 年數(shù)據(jù)；免費保留近7 天數(shù)據(jù)最大vCPUCPU瓶頸SQL等待/高CPU簡化管理自動存儲擴展，最高64 TB自動實現(xiàn)重新條帶化、鏡像修復(fù)、熱點管 理以及加密最高64 TB讀取端點具有負載均衡功能讀取端點自動規(guī)模伸縮定制化讀取端點主節(jié)點讀取 副節(jié)點讀取 副節(jié)點讀取副節(jié)點共享分布式存儲卷讀取端點讀取端點#2應(yīng)用場景（不影響生產(chǎn)環(huán)境）克隆生產(chǎn)數(shù)據(jù)庫以運行測試執(zhí)行密集工作負載，如生成月度報表克隆數(shù)據(jù)庫而不復(fù)制數(shù)據(jù)瞬間創(chuàng)建一個數(shù)據(jù)庫克隆僅在發(fā)生寫入時復(fù)制數(shù)據(jù)(COW) 當原始數(shù)據(jù)和克隆卷數(shù)據(jù)不同時生產(chǎn)數(shù)據(jù)庫克隆克隆克隆應(yīng)用開發(fā)/測試密集工作負載生產(chǎn)系統(tǒng)生產(chǎn)系統(tǒng)Aurora數(shù)據(jù)庫克隆技術(shù)Amazon AuroraServerless . .自動響應(yīng)您的應(yīng)用程序負載在10 秒以內(nèi)實現(xiàn)容量規(guī)模伸縮新實例默認配備w a r m 緩沖池多租戶代理具有高可用性區(qū)域可用區(qū)1App共享分布式存儲卷多租戶NLB/數(shù)據(jù)庫代理層Aurora實例warm池監(jiān)控服務(wù)工作原理其在實踐當中如何起效？0500100015002000250010130250370490610730850970109012101330145