PolarDB資料庫代理有哪些常見問題 - PolarDB

本文匯總了PolarDB資料庫代理相關的常見問題。

為什麼剛插入的語句，立即查的時候查不到？

讀寫分離的架構下，主節點和唯讀節點之間複製會有延遲，但PolarDB支援會話一致性，即同一個會話內保證能讀到之前的更新，詳情請參見會話一致性。

PolarDB叢集的主節點和唯讀節點在正常負載情況下，具有毫秒級的延遲，讀寫分離串連地址暫時不支援在資料寫入後0毫秒的讀取。如果要求0毫秒延遲的讀取，可使用主地址（動態指向PolarDB主節點）將讀寫請求發給主節點。如何查看主地址，請參見查看串連地址和連接埠。

主節點CPU負載高的原因有多種，常見的排查方法如下：

如果業務直接存取主地址，可以檢查一下是否有業務配置使用主地址。
業務的更新要求數量遠高於讀請求數量，導致主節點壓力大。
如果Proxy 位址將主庫是否接受讀設定為是，您可以將主庫是否接受讀修改為否，以減少部分讀請求路由到主節點。
檢查Proxy 位址事務拆分是否開啟。有些ORM預設將所有請求封裝在事務裡，導致所有請求都路由到主節點。可以開啟事務拆分，減少事務寫前讀請求路由到主節點。

若在Sysbench壓測中，您可以在0.5版本的Sysbench中加上--oltp-skip-trx=on或在1.0版本的Sysbench中加上--skip-trx=on去掉事務後再進行壓測。詳細的負載平衡策略及事務拆分請參見負載平衡。

當前是根據負載來分發請求的，負載小的節點接收的請求數會更多。

是的。

全域一致性（強）相比最終一致性（弱）和會話一致性（中）會有一定的效能損失。如果您的業務對並發數要求較高，請在業務低穀期進行層級變更設定。

如果刪除可讀可寫入模式的叢集地址下的唯讀節點，當刪除的唯讀節點上有正在執行中的請求、事務或暫存資料表時，該叢集地址上的Business Connectivity會直接斷連。否則，業務無感知。
如果刪除唯讀模式的叢集地址下的唯讀節點，該叢集地址上的Business Connectivity會直接斷連。

刪除唯讀節點的具體影響請參見唯讀節點下線。

當前PolarDB的叢集和自訂地址支援兩種讀寫入模式：唯讀和可讀可寫（自動讀寫分離）。

讀模式：所有請求僅會被路由到唯讀（RO）節點，寫入（RW）節點無法掛載到唯讀地址。如果業務請求嘗試串連到唯讀地址進行寫入，將會收到錯誤提示。此模式支援基於串連數和基於活躍請求數的負載平衡。
可讀可寫入模式：系統自動支援讀寫分離，預設情況下會掛載寫入（RW）節點。該模式僅支援基於活躍請求數的負載平衡。

修改讀寫入模式僅對建立串連生效，已有的老串連保持原來的模式。詳細配置請參見：設定資料庫代理。

目前基於串連數負載平衡的唯讀地址不支援在non-block模式下拉取Binlog檔案，請在控制台將唯讀地址的負載平衡策略切換為基於活躍請求數。

當前PolarDB MySQL版資料庫代理包含1.x.x和2.x.x兩大版本，兩個版本的區別如下：

1.x.x
2021年2月1日前建立的叢集下的資料代理版本，該版本不再進行新功能反覆式開發法，只進行問題修複。
2.x.x
2021年2月1日（包含）後新建立的叢集下的資料代理版本，該版本屬於當前的主流版本，所有的新增功能都在該版本上進行反覆式開發法。新增的功能包括串連保持、資料脫敏等。

不可以，1.x.x的資料庫代理版本只能升級到1.x.x的最新版本，不能直接升級到2.x.x。若您有相關需求，請參見資料庫代理版本可以從1.x.x升級到2.×.x。

可以，但您的叢集需要滿足如下要求：

若您的叢集滿足以上要求，可以聯絡我們為您處理。

是的。大版本升級的時候，資料庫代理版本會自動升級2.x.x版本，且不支援指定到1.x.x版本。

情境描述：需要將叢集地址中的唯讀節點移除。為避免對該節點上的串連造成影響，首先將該唯讀節點的讀寫分離權重設定為0。預期在權重設定為0後，後續的讀請求將不會被下發至該唯讀節點。在隨後將該節點移除叢集地址後，業務端出現串連錯誤。
問題原因：叢集地址有兩種负载均衡策略，分別為基于活跃请求数负载均衡和基于连接数负载均衡：
- 基于活跃请求数负载均衡：將唯讀節點的權重降低至0後，後續請求將不再路由至該節點。
- 基于连接数负载均衡：僅在建立串連階段進行負載平衡。如果之前已建立的串連，串連至唯讀節點，則後續該串連的請求將始終發送到該唯讀節點。
解決方案：
1. 將叢集地址中的负载均衡策略切換至基于活跃请求数负载均衡。
2. 將目標唯讀節點的讀寫分離權重設定為0。
3. 移除該唯讀節點。