'udb 數據庫讀寫分離中間件'

最近發現公司項目中用到了UDB，不瞭解上網查了下資料，現在整理出來分享下

UDB目前已提供完整的讀寫分離方案，具體做法如下：

1、在UDB控制檯上， 創建好1個主庫多個從庫。

2、在UDB控制檯上進入讀寫分離頁面，並開啟讀寫分離， 從而創建出讀寫分離中間件。該中間件作為業務程序和1主多從集群之間的代理，中轉業務程序發往主庫和從庫的請求。

3、讀寫分離中間件將識別業務SQL請求的類型，如果是寫請求，則一律轉發到主庫， 如果是讀請求，則根據某種分發規則（分發規則可配置），將讀請求分發到主庫或者從庫。

4、讀寫分離中間件具有獨立的IP。 使用讀寫分離中間件時，客戶將業務的數據庫訪問地址，直接切換到該IP即可，無需修改業務程序代碼， 支持標準SQL、系統命令、事務、視圖、存儲過程、觸發器等MySQL功能。

UDB讀寫分離中間件是永久免費的， 客戶只需要創建好主從庫，即可開啟並使用讀寫分離中間件，無需額外費用。普通版UDB和高可用UDB均支持創建讀寫分離中間件。

開啟讀寫分離

在UCloud控制檯， 創建好UDB主從節點之後， 點擊詳情到達管理二級頁面，即可看到讀寫分離：

在讀寫分離頁面點擊開啟讀寫分離：

點擊確認開啟成功後，控制檯可以看到讀寫分離Proxy的詳細信息，並進行管理，如關閉、重啟、設置等管理：

修改延遲閾值

點擊讀寫分離管理頁面延遲閾值欄的編輯圖標， 即可修改延遲閾值：

修改讀模式

點擊讀寫分離管理頁面讀模式欄的編輯圖標或點擊設置讀寫分離按鈕， 即可修改讀模式：

如圖所示， 一個讀寫分離中間件由兩個高性能 Proxy 節點和 UCloud 分佈式負載均衡產品 ULB 構成。

兩個 Proxy 採用雙活模式部署， 前端採用 ULB 來做負載均衡和容災，保證整個系統無單點。 客戶可以對讀請求的分發方式，進行自定義配置（配置方法詳見下文），Proxy 節點根據客戶配置分發讀請求。

讀寫分離中間件對業務請求的處理方式非常簡單， 有三個基本原則：

1. 從業務請求中，識別Select SQL， 只有Select SQL才考慮做讀寫分離；
2. 如果該Select SQL處於一個事務當中， 則將該Select SQL發往主節點，如果該Select SQL不處於事務當中， 則根據讀請求分發策略， 將該Select SQL發往主節點或者從節點。
3. 對於一些必須要廣播的語句， 如Use database、Set Session變量等語句，由中間件進行廣播，如果廣播未全部成功，則中斷客戶端連接，以此嚴格保證各節點的數據一致性。

以及針對一些特殊情況的修正：

1. 涉及到鎖的Select語句， 如Select For Update 、 Select Lock 等， 將被分發到主節點。
2. 將Set語句中的變量， 分為三種類型： Session、Global、User。 set Session、Set User變量語句將被廣播；考慮到節點間數據一致性問題， Set Global只會分發到主節點。 後續含全局變量的 Select 語句， 也只會發送到主節點。

功能限制

1.MySQL協議限制

1.1 不支持SSL加密

1.2 暫不支持壓縮協議

1.3 暫不支持綁定除3306之外的端口，UDB主從節點端口也必須為3306

2.SQL限制

2.1 支持savepoint語句（該語句將被分發到主節點）， 但暫不支持 rollback to savepoint

2.2 暫不支持XA事務命令

2.3 Lock Tables/Unlock Tables 將被分發到主節點，而Proxy層不會有任何Lock狀態。因此， Lock Tables產生的鎖不會影響到從節點。

2.4 存儲過程，以及存儲過程後的Select語句， 一律分發到主節點。如：

call udb_test('000001',@pp,@qq);
select @pp,@qq;
select * from t1;

上述兩條 Select 語句，都將被分發到主節點。

2.5 show processlists、Show master/slave status、kill query、COMPROCESSINFO、COM_STATISTICS命令，目前只會轉發到主節點，針對中間件和數據庫系統管理場景的， 更豐富的系統管理命令正在開發中。

2.6 暫不支持COM_TABLE_DUMP和COM_CHANGE_USER協議。

3.對Set語句的特別說明

3.1 Set Session、Set User變量語句， 將被廣播到主節點和從節點，如果廣播失敗，Proxy將斷開和客戶端連接， 從而撤銷廣播失敗導致的數據不一致； 考慮到節點間的數據一致性， Set global變量語句只會被分發到主節點。 後續含全局變量的 Select 語句， 也只會發送到主節點。

3.2 不允許在一條Set語句中，同時出現Global變量和Session、User變量。

4.不推薦使用讀寫分離的場景

a. 業務的SQL均為事務SQL（所有SQL都包含在事務中）， 由於事務只能被路由到主節點，故該場景下UDB讀寫分離無法起到分離讀請求的作用

b. 業務使用了大量存儲過程。 由於存儲過程只能被路由到主節點，故該場景下UDB讀寫分離無法起到分離讀請求的作用需要修改的點

c. 不推薦業務使用短連接來訪問讀寫分離。 UDB讀寫分離中間件處理業務數據庫連接的邏輯是： 業務每向讀寫分離中間件發起一個連接，讀寫分離會到每個主從節點均建立一個連接，用於後續的SQL轉發。 因此，如果業務使用短連接訪問讀寫分離，且業務發起短連接的頻率非常高，則讀寫分離中間件將頻繁地建連-斷連， 在進程內部產生大量TIME WAIT的TCP連接，佔用甚至耗盡進程的句柄數，導致業務新來連接無法建立。