深刻解讀阿里雲數據庫POLARDB核心功能物理複製技術

日誌是數據庫的重要組成部份，按順序以增量的方式記錄了數據庫上全部的操做，日誌模塊的設計對於數據庫的可靠性、穩定性和性能都很是重要。 可靠性方面，在有一個數據文件的基礎全量備份後，對運行中的數據庫來講，日誌文件的重要性大於數據文件，只要操做記錄到日誌中並完成落盤，就等於操做完成，無須等待數據文件落盤。由於日誌的順序和增量方式，使得數據庫的增量實時備份（包括備庫）成爲可能，更可使用異步、同步或Raft多數等方式經過保護日誌來保護全部的數據。

穩定性方面，日誌的增量模式減小了須要寫出的數據量，日誌的順序寫對於IO操做十分友好，能夠充分節約尋道時間（機械硬盤）和寫入緩存，使得日誌的寫操做能夠十分平穩，在面對高併發的事務時，不易出現劇烈的抖動，從而獲得高的穩定性和性能。按照日誌的組織形式，能夠分爲物理日誌和邏輯日誌，物理日誌使用更偏向底層數據塊操做的方式來描述變動，邏輯日誌則偏向於使用記錄鏡像或SQL語句的方式來描述變動，事務引摯通常使用物理日誌的模式來記錄事務的底層操做，而非事務引摯則通常使用邏輯日誌的方式。

用編程語言來打比方的話，物理日誌至關於使用匯編語言來記錄了操做，而邏輯日誌則至關於使用Go/Python等級別的語言來記錄操做，物理日誌相比邏輯日誌具備更高的可靠性、穩定性和性能。回顧數據庫的歷史，商業數據庫都只支持物理日誌，歷來沒有邏輯日誌的說法。MySQL由於其上下分層（SQL層和引摯層）的設計致使事務存貯引摯層必須有獨立的物理日誌，以及多引摯支持的緣由，必須在SQL層設計邏輯日誌以透明化不一樣存儲引摯（主備能夠不一樣引摯）的支持，造成了一個雙日誌的現狀，對MySQL的穩定性和性能帶來了極大的困難和挑戰。

物理日誌因其格式比較底層，使其很是難以建立只讀實例，而且從只讀實例切換爲讀寫實例須要比較長的時間，能夠參考Oracel數據庫的發展歷程，長久以來一直沒有支持隨時只讀的備庫，將備庫切換爲主庫須要極期嚴格的步驟，須要比較長的時間，比較難以實現自動化，沒法輕鬆實現互聯網讀擴展流量擴展的需求。而邏輯日誌因其格式比較上層，使其很是容易建立只讀實例，從只讀實例轉換爲讀寫實例能夠在秒級完成，並造成了一整套的增量數據訂閱消費。MySQL在享受邏輯複製好處時，也承受了邏輯複製帶來的一些限制：

• 存儲引摯層難以直接產生邏輯日誌，爲了數據的一致性，在物理日誌和邏輯日誌之間引入了XA（2PC）機制，給穩定性和性能帶來了極大的限制和挑戰，致使事務處理性能和傳統商業數據庫相比有較大差距，基於物理日誌則差距極小。
• 同一事務的MySQL邏輯日誌須要連續寫出，所以沒法支持較大的事務操做，過大的事務會致使操做失敗。基於物理日誌，同一個操做的日誌能夠分段（事務開始、操做一、操做二、事務提交）寫出，所以能夠支持大事務操做。
• MySQL現有邏輯日誌保存了整條記錄的先後鏡象，形成邏輯日誌寫入量較大增長IO壓力，易引發性能降低和抖動。物理日誌只記錄變化字段，格式緊湊以減小總日誌量，具有較好的IO性能，不易引發性能降低和抖動，肯有更高的性能和穩定性。
• MySQL邏輯日誌，在回入時須要從新通過SQL層代碼，執行路徑較長，而且不易並行處理，易形成備庫時延，即邏輯日誌產生的速度超過回放的速度；物理日誌因包含完整事務信息，更易用事務一致性實現並行回放，可極大提高備庫恢復的速度，作到高壓力下主備ms級時延。以下圖：

• MySQL邏輯日誌，不包含事務信息，沒法作連續性檢測，能夠從任意點開始恢復，不熟悉不專業的操做容易，形成問題；物理日誌包含完整事務信息，能夠作連續性檢測，會自動識別上一次的中斷點，減小人工判斷操做，可有效防止人爲誤操做。

所以基於邏輯複製的MySQL在大表加字段、建索引等操做上，主備複製的體驗很是不夠好。POLARDB在充分認識到MySQL邏輯複製的優缺點後，選擇以物理複製爲基礎實現複製節點（Replica），提高了主備複製的效率和體驗，爲廣大客戶提供了穩定、可靠、高性能能的只讀節點，引領了新一代複製技術的發展。

相關文章：

• 雲數據庫POLARDB優點解讀系列文章之①——10分鐘入門
• 雲數據庫POLARDB優點解讀系列文章之②——高性價比
• 雲數據庫POLARDB優點解讀系列文章之③——分鐘級彈性
• 雲數據庫POLARDB優點解讀系列文章之④——物理複製
• 雲數據庫POLARDB優點解讀系列文章之⑤——會話讀一致性

1月19日，阿里雲數據庫技術沙龍——雲原生數據庫POLARDB核心技術分享將在北京昆泰酒店舉行，對POLARDB核心技術細節感興趣的同窗歡迎點擊連接報名參加～

 

原文連接
更多技術乾貨 請關注阿里云云棲社區微信號 ：yunqiinsight