【巡檢問題分析與最佳實踐】PolarDB 流量 & 代理問題

往期分享

RDS MySQL

RDS MySQL 執行個體空間問題 RDS MySQL 記憶體使用問題 RDS MySQL 活躍線程數高問題 RDS MySQL 慢SQL問題 RDS MySQL 執行個體IO高問題 RDS MySQL 小版本更新最佳實踐

RDS PostgreSQL

RDS PostgreSQL 執行個體IO高問題 RDS PostgreSQL 慢SQL問題 RDS PostgreSQL CPU高問題

RDS SQL Server

RDS SQL Server 磁盤IO吞吐高問題 RDS SQL Server CPU高問題 RDS SQL Server 空間使用問題

PolarDB

PolarDB MySQL CPU高問題

Redis

Redis 流控問題 Redis 記憶體高問題 Redis CPU高問題

MongoDB

MongoDB 記憶體高問題 MongoDB 磁盤IO高問題 MongoDB 空間使用問題

概述

PolarDB叢集原生支援讀寫分離方式接入業務，但是在真實業務中，經常出現節點上負載不均情況，嚴重的話可能導緻單節點承擔大量的流量被拖跨，最終整個叢集雪崩影響業務。

本文主要描述PolarDB代理的配置方法以及流量不均時如何定位。

資料庫代理

基本資訊

在RDS MySQL産品中，資料庫代理需要單獨購買并配置，而在PolarDB M叢集中，預設即開啟資料庫代理功能，同時功能也比 MySQL的資料庫代理更為強大。

• 主位址：讀寫，直接指向主節點，隻能配置連接配接名，無法配置代理功能
• 叢集位址：讀寫方式可配置，支援标準代理配置，不可删除
• 自定義位址：讀寫方式可配置，支援标準代理配置，可删除

位址配置(ENDPOINT)

隻讀類型

在標明讀寫模式是【隻讀】類型的情況下，配置項比較少，需要注意的是隻讀類型的endpoint如果隻使用單節點，盡量不要應用在生産環境中。

另外可調整的參數是【并行查詢】，此配置隻在隻讀endpoint中可配置，在PolarDB 8.0 中支援了并行查詢，如果隻讀endpoint承接一些AP類業務流量，可以單獨提供隻讀節點給此endpoint，并且盡量和TP業務節點不要重合，同時對并行查詢的并行度單獨調整，以充分利用CPU資源執行并行查詢。

讀寫類型

讀寫類型中需要注意的點主要是

• 一緻性級别

• • 最終一緻性：不考慮資料的同步情況，按負載進行節點請求的排程，會出現寫入的資料未同步完成，隻讀節點上讀取不到的情況，抽象如圖：

• • 會話一緻性：簡單了解就是指在同一個連接配接裡的前後請求，一般在寫入後立即請求資料時使用，也是PolarDB推薦的一緻性配置，抽象如圖：

• • 全局一緻性：每一個會話都要判斷隻讀節點是否已經同步到最新資料，對一緻性要求最高的場景下啟用，抽像如圖：

• • 以上三種一緻性級别，需要根據業務需求配置。

• 主庫不接受讀：滿足一緻性需求的前提下，将讀請求全部分流到隻讀節點執行，如果不滿足一緻性需求（隻讀同步完成），流量還是會路由到主執行個體。
• 事務拆分：将事務頭部的讀取語句拆分到隻讀節點上以承擔主節點壓力，如圖：

• 連接配接池

• • 會話級連接配接池：用以緩存連接配接資訊，主要是連接配接風暴的場景下使用，例如PHP大量短連接配接的場景下，無法控制連接配接到執行個體的總連接配接數
  • 事務級連接配接池：标準連接配接池方案，對長連接配接進行複用，類似Druid等連接配接池中間件，控制連接配接執行個體的總連接配接數

注意

• endpoint配置讀寫模式時，系統表查詢會被路由到主節點，即使節點沒有配置在目前endpoint，可能對一些業務場景有影響，例如：

select * from information_schema.processlist;      

• 讀寫模式下，即使沒有配置主節點，寫請求會自動路由到主節點
• 如果對一緻性有要求，推薦使用會話一緻性，可以滿足大部分業務場景，如果小部分業務的一緻性要求不能在同一會話中完成（dml ->select)，可以考慮使用hint方式強制讀主節點，例如：

/*FORCE_MASTER*/ select * from information_schema.processlist;      

流量定位

有時觀察執行個體性能，會發現執行個體的流量不均勻，需要定位原因，防止流量傾斜導緻的執行個體性能問題。

常見問題

• 主節點負載高， 隻讀節點負載低的情況

• • 場景一：都是業務側直接連接配接了主位址導緻隻讀沒有分流，特别是在【RDS一鍵遷移PolarDB】的最終切換過程中，預設原RDS位址會切換到PolarDB的主位址上，這種情況下會導緻流量全部流轉到rw節點。此類問題需要業務側調整連接配接位址為叢集或自定義位址。
  • 場景二：使用的是讀寫分離位址，但業務上有大量的寫，在代理層會把所有的寫流量路由到主節點。此類場景可以嘗試打開【主庫不接受讀】和【事務拆分】，盡可能讓隻讀節點承擔一些讀流量

• 隻讀節點負載高，主節點負載低

• • 此類場景一般是預期内的隻讀節點承截流量，例如配置了主不接受讀和事務拆分，同時大量的請求都是讀請求時，此類場景是比較理想的PolarDB流量配置設定，即使隻讀節點資源不夠，也可以通過快速添加新的隻讀節點以分擔負載，監控曲線例如：

以上兩種都是預期内的負載配置設定，但有可能負載情況不在預期，如叢集位址中有多個隻讀節點，但隻有某個節點負載非常高，此類情況就需要定位是否有流量異常或者執行個體性能異常的情況。

異常定位

• 執行個體複用

• • 由于PolarDB可以自定義多個endpoint，不同endpoint之前節點也可以複用，就有可能造成流量交叉導緻執行個體負載不平均，例如TP業務和 AP業務不同的位址，但配置了相同的隻讀節點，如果出現交叉使用的節點負載異常，有很大可能就是不同業務之間的資源争搶，可以嘗試将問題節點從某個位址中摘除，再對比負載情況。
  • 另外不建議節點交叉部署。

• 執行個體本身性能問題

• • 在某些情況下，執行個體可能是由于自身問題導緻資源負載高，例如在《PolarDB MySQL CPU高問題》 一文提到的AHI問題，不同節點配置設定的流量會導緻AHI的配置設定也不相同，可能會導緻某個節點上出現争搶問題，此時就要定位具體原因以優化節點性能。另外代理層是按負載情況配置設定的，如果單節點負載高，流量也會自動向負載低的節點傾斜，可能導緻叢集性能整體出現問題。

• 來源定位

• • 目前PolarDB還未完全接入DAS曆史資料診斷，如果需要定位異常流量來源，隻能觀察目前連接配接請求的情況，在一鍵診斷->會話管理 入口，可以檢視用Hosts次元會話的統計，以确認是否有非預期的業務來源通路。同時可将正常節點與異常節點做對比以定位異常流量來源