本文作者 黃忠（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），提升了主備複制的效率和體驗，為廣大客戶提供了穩定、可靠、高性能能的隻讀節點，引領了新一代複制技術的發展。
相關文章：
- 雲資料庫POLARDB優勢解讀系列文章之①——10分鐘入門
- 雲資料庫POLARDB優勢解讀系列文章之②——高成本效益
- 雲資料庫POLARDB優勢解讀系列文章之③——分鐘級彈性
- 雲資料庫POLARDB優勢解讀系列文章之④——實體複制
- 雲資料庫POLARDB優勢解讀系列文章之⑤——會話讀一緻性
1月19日，阿裡雲資料庫技術沙龍——雲原生資料庫POLARDB核心技術分享将在北京昆泰酒店舉行，對POLARDB核心技術細節感興趣的同學歡迎
點選連結報名參加～
