問題與解決方案

MySQL的讀寫分離代理功能，代理會偽造成MySQL與應用程序建立好連接，解析發送進來的每一條SQL，如果是UPDATE、DELETE、INSERT、CREATE等寫操作則直接發往主庫，如果是SELECT則發送到備庫，從而實現了讀寫分離。但是當數據庫負載很高時，例如對大表執行DDL（如加字段）操作或大批量插入數據的時候，延遲會非常嚴重，從而導致無法從只讀節點中讀取最新數據。MySQL的讀寫分離代理功能無法解決由于延遲導致的查詢不一致問題。

PolarDB采用了異步物理復制方式實現了主節點和只讀節點間的數據同步。主節點的數據更新后，相關的更新會應用到只讀節點，具體的延遲時間與寫入壓力有關（一般在毫秒級別），通過異步復制的方式確保了主節點和只讀節點間數據的最終一致。PolarDB提供了如下四種一致性級別，滿足您在不同場景下對一致性級別的要求：

• 最終一致性

• 會話一致性

• 全局一致性

• 全局一致性（高性能模式）

最終一致性

• 功能介紹

  PolarDB是讀寫分離的架構，傳統的讀寫分離只提供最終一致性的保證，主從復制延遲會導致從不同節點查詢到的結果不同，例如在一個會話內連續執行如下查詢，最后的SELECT結果可能會不同（具體的訪問結果由主從復制的延遲決定）。

  INSERT INTO t1(id, price) VALUES(111, 96);
  UPDATE t1 SET price = 100 WHERE id=111;
  SELECT price FROM t1;

• 適用場景

  若需要減輕主節點壓力，讓盡量多的讀請求路由到只讀節點，您可以選擇最終一致性。

會話一致性

• 功能介紹

  針對最終一致性導致查詢結果不同的問題，通常需要將業務進行拆分，將一致性要求高的請求直接發往主節點，而可以接受最終一致性的請求則通過讀寫分離發往只讀節點。這既增加了主節點的壓力，影響讀寫分離的效果，又增加了應用開發的負擔。

  為解決上述問題，PolarDB提供了會話一致性（也稱因果一致性）。會話一致性保證了同一個會話內，一定能夠查詢到讀請求執行前已更新的數據，確保了數據單調性。

  在PolarDB的鏈路中間層做讀寫分離的同時，中間層會追蹤各個節點已經應用的Redo日志位點，即日志序號（Log Sequence Number，簡稱LSN）。同時每次數據更新時PolarDB會記錄此次更新的位點為Session LSN。當有新請求到來時，PolarDB會比較Session LSN和當前各個節點的LSN，如果只讀節點的LSN不滿足，會根據您配置的超時時間等待只讀節點同步到最新數據，僅將請求發往LSN大于或等于Session LSN的節點，從而保證了會話一致性。表面上看該方案可能導致主節點壓力大，但是因為PolarDB是物理復制，速度極快。

  

  在上述場景中，當更新完成后，返回客戶端結果時復制就同步在進行，而當下一個讀請求到來時，主節點和只讀節點之間的數據復制極有可能已經完成。且大多數應用場景都是讀多寫少，所以經驗證在該機制下既保證了會話一致性，又保證了讀寫分離負載均衡的效果。

• 適用場景

  PolarDB的一致性級別越高，對主庫的壓力越大，集群性能也越低。推薦使用會話一致性，該級別對性能影響很小而且能滿足絕大多數應用場景的需求。

全局一致性

• 功能介紹

  在部分應用場景中，除了會話內部有邏輯上的因果依賴關系，會話之間也存在依賴關系，例如在使用連接池的場景下，同一個線程的請求有可能通過不同連接發送出去。對數據庫來說這些請求屬于不同會話，但是業務邏輯上這些請求有前后依賴關系，此時會話一致性便無法保證查詢結果的一致性。因此PolarDB提供了全局一致性來解決該問題。

  

  每個讀請求到達PolarDB數據庫代理時，代理都會先去主節點確認當前最新的LSN位點，假設為LSN0（為了減少每次讀請求都去獲得主節點的最新LSN，內部做了批量優化）， 然后等待所有只讀節點的LSN都更新至主節點的LSN0位點后，代理再將讀請求發送至只讀節點。這樣就能保證該讀請求能夠讀到至請求發起時刻為止，任意一條已完成更新的數據。

  全局一致性提供如下兩個配置參數：

  參數	說明
  ConsistTimeout	全局一致性讀超時時間，讀請求等待只讀節點同步LSN（位點）的最長時間。若超出該時間，PolarDB代理將根據ConsistTimeoutAction參數設置進行對應操作。 取值范圍：0~60000。默認值為20。單位為毫秒。
  ConsistTimeoutAction	全局一致性讀超時策略，若未能在參數ConsistTimeout設置的時間內將只讀節點的LSN更新至主節點最新LSN，PolarDB代理將根據ConsistTimeoutAction參數設置進行對應操作。 取值范圍如下： 0（默認）：將讀請求發送到主節點。 1：代理返回一個錯誤報文wait replication complete timeout, please retry給應用端。

  說明

  如何修改全局一致性讀超時時間和全局一致性讀超時策略，請參見配置數據庫代理。

• 適用場景

  當主從延遲較高時，使用全局一致性可能會導致更多的請求被路由到主節點，造成主節點壓力增大，業務延遲也可能增加。因此建議在讀多寫少的場景下選擇全局一致性。

全局一致性（高性能模式）

PolarDB MySQL版推出了全局一致性（高性能模式）服務。全局一致性（高性能模式）具有比全局一致性更嚴格的強一致性要求。

PolarTrans事務系統利用提交時間戳技術CTS和RDMA網絡，在純內核層面提供RO節點強一致性讀服務，從而保證始終能看到RW和RO節點最新的數據，提供了集群維度的強一致性讀能力，保證發往集群任意副本的讀請求都可以獲得強一致性的結果。

關于全局一致性（高性能模式）的更多細節（如使用限制、技術原理、開啟方式以及性能數據等），請參見全局一致性（高性能模式）。

如何選擇一致性級別

• PolarDB一致性級別越高，集群性能越低。

  推薦使用會話一致性，該級別對性能影響很小而且能滿足絕大多數應用場景的需求。

• 若對不同會話間的一致性需求較高，可以選擇如下方案之一：

  • 選擇全局一致性（高性能模式）或全局一致性。

    說明

    • 對于PolarDB MySQL版5.7、8.0.1和8.0.2版本，若追求嚴格強一致性，更推薦全局一致性（高性能模式）。

    • 對于PolarDB MySQL版5.6版本，若追求嚴格強一致性，由于該版本暫不支持全局一致性（高性能模式），可選擇全局一致性。

  • 使用HINT將特定查詢強制發送至主節點執行。

    /*FORCE_MASTER*/ select * from user;

    說明

    • 若您需要通過MySQL官方命令行執行上述Hint語句，請在命令行中加上-c參數，否則該Hint會被MySQL官方命令行過濾導致Hint失效，具體請參見MySQL官方命令行。

    • Hint的路由優先級最高，不受一致性級別和事務拆分的約束，使用前請進行評估。

    • Hint語句里不要有改變環境變量的語句，例如/*FORCE_SLAVE*/ set names utf8;等，這類語句可能導致后續的業務出錯。

如何設置一致性級別

• 如何設置為全局一致性（高性能模式），請參見如何開啟全局一致性（高性能模式）。

• 如何設置為最終一致性、會話一致性和全局一致性，請參見配置數據庫代理。