背景介紹
讀寫分離是資料庫常見的使用模式。類似MySQL proxy這樣的中間件把寫入和更新流量發送到主節點，把查詢流量轉發到隻讀節點，可以釋放主節點的CPU和IO資源，提升資料庫整體的可用性。
在《RDS三節點企業版 · 一緻性協定》文章中，我們介紹了三節點企業版借助X-Paxos的Learner角色，實作了隻讀執行個體的功能。
Learner特性
三節點企業版通過新加Learner的方式實作隻讀執行個體的功能。Learner從Leader接收已經送出的日志存儲到consensus log中，由Slave線程讀取并分發給worker線程，最終并行回放到狀态機。對于外部用戶端來說，Learner節點是隻讀狀态的。
實際上用過MySQL雲産品的人，對隻讀節點的概念并不陌生。在雙節點高可用版本中，初始狀态會生産兩個執行個體。一個作為Master，是提供讀寫的主節點。
另一個作為Slave，是處于read only狀态的備節點，不過該節點不暴露給客戶，也不對外提供讀服務。如果需要增加隻讀執行個體支援讀寫分離，控制台背景會通過備份建立一個Slave節點，挂載在Master上。當該節點追平Master最新的資料後，即Second_Behind_Master追到0，對外開啟讀服務。部署模式如下：
三節點企業版的隻讀節點十分類似，首先通過備份建立一個新的Learner節點，并挂載在Leader上，挂載後Learner開始接收增量的consensus log并開始回放。當Learner節點的日志回放追平後，對外開啟讀服務。部署模式如下：
相比高可用版本的隻讀節點，Learner的優勢在于接入到X-Paxos的體系中，保證了主節點（Leader/Master）和災備節點（Follower/Slave）無論如何容災切換，Learner都會保持和三節點叢集一緻的資料。
考慮這樣一個場景：雙節點高可用場景下，主庫把x=1更新成x=2，同步給了隻讀節點但還未同步給備庫，之後主庫故障。備庫會切換成新的主庫，隻讀節點也會指向這個備執行個體。這個時刻新主庫和隻讀節點的資料就出現了不一緻，新主庫x=1，隻讀節點x=2。如果此時業務或DBA檢測到資料庫的不一緻問題，執行資料回補，在新的備庫重新執行把x=1更新成x=2。當這個事務binary log同步到隻讀節點，就會造成隻讀節點的SQL線程報錯退出，需要人工介入處理。假設這個回補的資料量很大，在人工運維上就完全沒有可操作性了，隻能基于新主庫的備份重搭隻讀節點，導緻隻讀節點一段時間的不可用。在三節點企業版中，就完全不會發生這樣的問題。
Learner的孵化
三節點企業版使用特殊版本的Xtrabackup進行執行個體備份和恢複。我們基于X-Paxos的snapshot接口改進了Xtrabackup，支援建立帶有一緻性位點的實體備份快照，可以十分快捷的孵化一個全新的Learner節點，并加入到叢集中提供讀能力的擴充。在即将推出的RDS 8.0三節點版本中，我們還會整合官方8.0新出的Clone Plugin功能，推出基于Clone Plugin的一緻性位點快照，Learner節點孵化功能運維會更簡單，速度也會更快。
Clone Plugin相關資料可以參考：
- https://mysqlserverteam.com/clone-create-mysql-instance-replica
- http://mysql.taobao.org/monthly/2019/08/05/
自定義資料源
三節點企業版的隻讀節點借助X-Paxos的LearnerSource功能，通過自定義資料源，輕松實作了靈活的複制拓撲。三節點的複制拓撲配置都是通過Leader上的Membership Change相關管控SQL指令完成的。通過中心化配置管理，保證叢集次元一緻。自定義資料源的好處是當隻讀節點數量較多時，可以分流Leader日志發送的壓力，打散網絡傳輸的資料量，減小日志同步的延遲。
三節點企業版的自定義資料源還支援基于region的load balance和LearnerSource的自動容災。具體來說，支援通過load balance功能一鍵将每個region的隻讀節點自動挂載到同region的Follower/Learner節點上。如果同region資料源出現故障，能夠将資料源短暫退化到Leader節點直到恢複。該拓撲保證了各自region的隻讀節點從同region的節點同步資料，通過這樣的級聯部署，極大地減少了跨region的網絡帶寬占用，避免了帶寬瓶頸造成的跨region延遲。
以下是阿裡巴巴集團内部的一個部署樣例：
當然傳統的MySQL也可以構造一系列Master-Slave-Slave這樣的拓撲，逐個執行個體通過change master配置複制關系，不過這種方式容錯性差，管理成本和運維成本都很高。同時随着隻讀節點數量的規模上升，主備容災後，資料不一緻的風險會被放大。
會話讀一緻性
隻讀節點接收日志并回放，接受外部查詢請求，這裡存在一個問題，Learner的日志同步和回放是異步的，雖然大部分場景延遲在5s以内，也不能保證每次查詢的資料一定是最新的。特别是主庫執行了大表DDL或者大事務，會造成隻讀節點出現明顯的延遲。為了解決這個問題，三節點企業版引入了MaxScale作為讀寫分離的代理，并在MaxScale中實作了會話讀一緻性，即在同一個Session内部，保證後續的讀取可以讀到之前同Session寫入的資料，但不保證可以讀到其他Session最新版本的資料。
X-Paxos的每一條日志都有一個LogIndex，對應Multi-Paxos概念中的Instance number。同時，隻讀節點在多線程亂序回放日志到狀态機的過程中，會維護日志并發回放的視窗，通過該視窗可以計算出一個已回放的Logindex的低水位線（Lwm AppliedIndex）。
在Lwm AppliedIndex之前的所有日志，都已經回放到狀态機，之後的日志，依然存在空洞。三節點企業版讀寫分離層的代理，會跟蹤緩存各個隻讀節點的Lwm AppliedIndex，同時每個Leader的更新，都會記錄目前事務的Logindex。當有新請求到來時代理層會比較Session最新的Logindex和目前各個隻讀節點的Lwm AppliedIndex，僅将請求發往Lwm AppliedIndex >= Session Logindex的節點，進而保證了會話一緻性。在讀多寫少的場景下，該機制可以起到非常好的讀寫分離效果。
總結
通過X-Paxos的Learner角色，支援建立隻讀執行個體，實作讀取能力的彈性擴充，分擔主資料庫壓力。利用隻讀執行個體滿足大量的資料庫讀取需求，增加應用的吞吐量。目前阿裡雲官網已經開放了RDS 5.7三節點企業版隻讀執行個體的建立和使用，歡迎試用。
相關閱讀
- 内附大神PPT | 最大化資源管理技術紅利， 阿裡雲重磅釋出RDS MySQL專屬主機組服務！
- https://developer.aliyun.com/article/742236
- 阿裡雲RDS vs 自建MySQL，這篇評測終結你的選擇困難症!
- https://developer.aliyun.com/article/742189
- 同樣是365天，但RDS for MySQL的這一年也太高産了...
- https://developer.aliyun.com/article/742127