雲資料庫POLARDB優勢解讀系列文章之④——物理複製
本文作者 黃忠（AnySQL）
日誌是資料庫的重要組成部份，按順序以增量的方式記錄了資料庫上所有的操作，日誌模組的設計對於資料庫的可靠性、穩定性和效能都非常重要。 可靠性方面，在有一個數據檔案的基礎全量備份後，對執行中的資料庫來說，日誌檔案的重要性大於資料檔案，只要操作記錄到日誌中並完成落盤，就等於操作完成，無須等待資料檔案落盤。因為日誌的順序和增量方式，使得資料庫的增量實時備份（包括備庫）成為可能，更可以使用非同步、同步或Raft多數等方式通過保護日誌來保護所有的資料。
穩定性方面，日誌的增量模式減少了需要寫出的資料量，日誌的順序寫對於IO操作十分友好，可以充分節約尋道時間（機械硬碟）和寫入快取，使得日誌的寫操作可以十分平穩，在面對高併發的事務時，不易出現劇烈的抖動，從而得到高的穩定性和效能。按照日誌的組織形式，可以分為物理日誌和邏輯日誌，物理日誌使用更偏向底層資料塊操作的方式來描述變更，邏輯日誌則偏向於使用記錄映象或SQL語句的方式來描述變更，事務引摯一般使用物理日誌的模式來記錄事務的底層操作，而非事務引摯則一般使用邏輯日誌的方式。
用程式語言來打比方的話，物理日誌相當於使用匯編語言來記錄了操作，而邏輯日誌則相當於使用Go/Python等級別的語言來記錄操作，物理日誌相比邏輯日誌具有更高的可靠性、穩定性和效能。回顧資料庫的歷史，商業資料庫都只支援物理日誌，從來沒有邏輯日誌的說法。MySQL因為其上下分層（SQL層和引摯層）的設計導致事務存貯引摯層必須有獨立的物理日誌，以及多引摯支援的原因，必須在SQL層設計邏輯日誌以透明化不同儲存引摯（主備可以不同引摯）的支援，形成了一個雙日誌的現狀，對MySQL的穩定性和效能帶來了極大的困難和挑戰。
物理日誌因其格式比較底層，使其非常難以建立只讀例項，並且從只讀例項切換為讀寫例項需要比較長的時間，可以參考Oracel資料庫的發展歷程，長久以來一直沒有支援隨時只讀的備庫，將備庫切換為主庫需要極期嚴格的步驟，需要比較長的時間，比較難以實現自動化，無法輕鬆實現網際網路讀擴充套件流量擴充套件的需求。而邏輯日誌因其格式比較上層，使其非常容易建立只讀例項，從只讀例項轉換為讀寫例項可以在秒級完成，並形成了一整套的增量資料訂閱消費。MySQL在享受邏輯複製好處時，也承受了邏輯複製帶來的一些限制：
- 儲存引摯層難以直接產生邏輯日誌，為了資料的一致性，在物理日誌和邏輯日誌之間引入了XA（2PC）機制，給穩定性和效能帶來了極大的限制和挑戰，導致事務處理效能和傳統商業資料庫相比有較大差距，基於物理日誌則差距極小。
- 同一事務的MySQL邏輯日誌需要連續寫出，因此無法支援較大的事務操作，過大的事務會導致操作失敗。基於物理日誌，同一個操作的日誌可以分段（事務開始、操作1、操作2、事務提交）寫出，因此可以支援大事務操作。
- MySQL現有邏輯日誌儲存了整條記錄的前後鏡象，造成邏輯日誌寫入量較大增加IO壓力，易引起效能下降和抖動。物理日誌只記錄變化欄位，格式緊湊以減少總日誌量，具備較好的IO效能，不易引起效能下降和抖動，肯有更高的效能和穩定性。
- MySQL邏輯日誌，在回入時需要重新經過SQL層程式碼，執行路徑較長，並且不易並行處理，易造成備庫時延，即邏輯日誌產生的速度超過回放的速度；物理日誌因包含完整事務資訊，更易用事務一致性實現並行回放，可極大提升備庫恢復的速度，做到高壓力下主備ms級時延。如下圖：
- MySQL邏輯日誌，不包含事務資訊，無法做連續性檢測，可以從任意點開始恢復，不熟悉不專業的操作容易，造成問題；物理日誌包含完整事務資訊，可以做連續性檢測，會自動識別上一次的中斷點，減少人工判斷操作，可有效防止人為誤操作。
因此基於邏輯複製的MySQL在大表加欄位、建索引等操作上，主備複製的體驗非常不夠好。POLARDB在充分認識到MySQL邏輯複製的優缺點後，選擇以物理複製為基礎實現複製節點（Replica），提升了主備複製的效率和體驗，為廣大客戶提供了穩定、可靠、高效能能的只讀節點，引領了新一代複製技術的發展。