前提條件

已創(chuàng)建ECS實例。建議ECS實例與Serverless集群位于同一地域和可用區(qū)。

購買與配置PolarDB集群

PolarDB的Serverless有以下兩種形態(tài)：

• Serverless集群：指創(chuàng)建一個新的Serverless集群，從頭開始使用Serverless功能。有更大的彈性范圍，所有資源完全按Serverless彈性計費。

• 固定規(guī)格集群的Serverless：指在已經(jīng)創(chuàng)建的普通集群上開啟Serverless功能。收費內(nèi)容包括固定規(guī)格費用和彈性費用。

購買集群

本文直接使用Serverless集群進(jìn)行測試，集群的基礎(chǔ)配置如下：

• 地域：華北2（北京）

• 數(shù)據(jù)庫引擎：PolarDB MySQL版8.0.1

• 主可用區(qū)：華北2 可用區(qū)K

以上是新購Serverless集群的一些關(guān)鍵選項，創(chuàng)建集群大約耗時5~10分鐘。集群購買成功后，進(jìn)入PolarDB控制臺，集群的系列會顯示為集群版（Serverless）。購買Serverless集群的詳細(xì)操作步驟，請參見創(chuàng)建Serverless集群。

配置白名單

在白名單中配置ECS實例的地址。配置白名單的詳細(xì)操作步驟請參見設(shè)置白名單。

創(chuàng)建數(shù)據(jù)庫賬號

創(chuàng)建測試使用的數(shù)據(jù)庫賬號polartest。創(chuàng)建數(shù)據(jù)庫賬號的詳細(xì)操作步驟請參見創(chuàng)建和管理數(shù)據(jù)庫賬號。

創(chuàng)建數(shù)據(jù)庫

創(chuàng)建測試使用的數(shù)據(jù)庫sbtest。創(chuàng)建數(shù)據(jù)庫的詳細(xì)操作步驟請參見創(chuàng)建數(shù)據(jù)庫。

擴(kuò)縮測試

數(shù)據(jù)準(zhǔn)備

測試開始之前，需要為sbtest庫準(zhǔn)備數(shù)據(jù)。該測試選擇了128張表，每張表1000000行數(shù)據(jù)。數(shù)據(jù)準(zhǔn)備過程中可能會造成集群規(guī)格彈升，所以數(shù)據(jù)準(zhǔn)備完成后建議等待1分鐘，直到主節(jié)點降回1 PCU后再進(jìn)行壓測。

-- threads不同的線程數(shù)可以構(gòu)造不同的負(fù)載，以xxx為例
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=http://xxxx.rwlb.rds.aliyuncs.com --mysql-port=3306 --mysql-user=xxxx --mysql-password=xxxx --mysql-db=sbtest --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=xxx --time=12000 prepare

請將本命令和后續(xù)步驟命令中的XXX替換為PolarDB MySQL版集群的集群地址、端口號、用戶名和密碼。具體參數(shù)說明如下，更多性能測試請參見性能測試方法（OLTP）。

單節(jié)點縱向擴(kuò)縮測試（Scale-up）

該測試通過Sysbench壓測，來驗證主節(jié)點的規(guī)格能夠根據(jù)負(fù)載進(jìn)行自動伸縮，達(dá)到Serverless能力。

Serverless配置

登錄PolarDB控制臺。在設(shè)置Serverless配置參數(shù)頁面，將單節(jié)點資源彈升上限設(shè)置為32，單節(jié)點彈升資源下限設(shè)置為1，只讀節(jié)點個數(shù)擴(kuò)展上限和只讀節(jié)點個數(shù)擴(kuò)展下限均設(shè)置為0。設(shè)置Serverless配置參數(shù)詳細(xì)操作步驟請參見設(shè)置Serverless集群資源擴(kuò)縮策略。

Sysbench壓測命令

Sysbench壓測使用的命令如下，該測試使用oltp_read_write模式。

-- threads不同的線程數(shù)可以構(gòu)造不同的負(fù)載，以xxx為例
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=http://xxxx.rwlb.rds.aliyuncs.com --mysql-port=3306 --mysql-user=xxxx --mysql-password=xxxx --mysql-db=sbtest --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=xxx --time=12000 run

其中，mysql-host的值需配置為集群地址，并配置--db-ps-mode=disable以確保所有的事務(wù)SQL以原始SQL語句的方式執(zhí)行。

測試結(jié)果

首先，簡單測試一下16個線程的測試效果。從Sysbench的輸出來看，在并發(fā)數(shù)量固定為16的負(fù)載下，隨著時間的推移，吞吐量TPS逐步增加，延遲LAT逐步降低，最終達(dá)到一個穩(wěn)定值。這說明PolarDB Serverless觸發(fā)彈性后，性能獲得了提升。

登錄PolarDB控制臺。在性能監(jiān)控頁面可以看到集群頁簽中展示了Serverless監(jiān)控指標(biāo)項。時間范圍選擇最近的5分鐘，可以看到如下監(jiān)控信息，查看性能監(jiān)控指標(biāo)的詳細(xì)操作步驟請參見查看性能監(jiān)控指標(biāo)。

PCU數(shù)量從1彈升到5，并保持穩(wěn)定。在彈升過程中，CPU的使用率隨著資源的擴(kuò)容而逐步降低。內(nèi)存使用率曲線中每次彈升會有脈沖形狀。這是因為每次PCU增加，內(nèi)存資源會進(jìn)行擴(kuò)容，此時的內(nèi)存使用率會瞬間降低。之后數(shù)據(jù)庫開始利用擴(kuò)充的內(nèi)存資源提高計算能力（比如Buffer Pool），因此內(nèi)存使用率會逐步增加，最終達(dá)到一個穩(wěn)定狀態(tài)。

停止Sysbench壓測，稍等一段時間，再調(diào)整合適的時間范圍，刷新后的監(jiān)控信息如下：

從監(jiān)控信息中可以看出。隨著壓力的停止，PCU數(shù)量從5逐步階梯式地降低至1。CPU使用率瞬間降為接近0。由于讀寫混合測試包含UPDATE請求，當(dāng)壓力停止后，PolarDB還會繼續(xù)執(zhí)行purge undo操作。因此，還會占用微量的CPU。再觀察內(nèi)存使用率，每次縮容內(nèi)存使用率會立即降低，然后再升高一個臺階。這是因為PolarDB縮容之前，會首先調(diào)小內(nèi)存相關(guān)參數(shù)（如Buffer Pool、Table Open Cache等）來觸發(fā)回收緩存，故使用率會立刻降低。參數(shù)調(diào)整完成后，確保內(nèi)存資源已經(jīng)被釋放，才會真正調(diào)小容器的Mem規(guī)格，當(dāng)Mem上限調(diào)小后，相當(dāng)于分母變小，計算出來的內(nèi)存使用率則會上升。

嘗試增加Sysbench壓力，將線程數(shù)量調(diào)整為128個，查看PolarDB彈升到最大規(guī)格32 PCU的時間。

從Sysbench輸出可以明顯看出TPS和LAT的變化。同樣地，壓測一段時間后停止Sysbench測試，PCU也會自動縮容。從1 PCU彈升至32 PCU耗時大約需要42秒。縮容相比擴(kuò)容稍顯平緩，耗時大約220秒。

多節(jié)點橫向擴(kuò)縮測試（Scale-out）

PolarDB借助SCC技術(shù)實現(xiàn)了全局一致性（高性能模式），可以實現(xiàn)跨節(jié)點無損讀擴(kuò)展。Serverless集群會在所有彈出只讀節(jié)點上默認(rèn)開啟SCC。傳統(tǒng)的MySQL主備一寫多讀集群的只讀節(jié)點存在Binlog復(fù)制延遲問題，一般不轉(zhuǎn)發(fā)TP業(yè)務(wù)的讀操作，僅服務(wù)報表這類對全局一致性不敏感的業(yè)務(wù)。同時，由于Binlog復(fù)制只會同步已提交事務(wù)的日志，只讀節(jié)點無法處理事務(wù)中的寫后讀。

PolarDB的SCC通過提交事務(wù)時間戳技術(shù)CTS與事務(wù)狀態(tài)RDMA保持同步，實現(xiàn)低延遲的只讀節(jié)點讀擴(kuò)展。同時，SCC加上Proxy的高級事務(wù)拆分技術(shù)，使得跨事務(wù)、事務(wù)前和事務(wù)中的寫后讀請求都可以輕松擴(kuò)展到PolarDB的只讀節(jié)點，且保證全局一致性。最終主節(jié)點省下來的資源就可以支持更多的寫請求。借助于SCC技術(shù)，PolarDB Serverless使用唯一的集群地址訪問集群，用戶不會受到跨節(jié)點的讀一致性的問題困擾，即用戶無需關(guān)心請求是由主節(jié)點直接執(zhí)行，還是被轉(zhuǎn)發(fā)到只讀節(jié)點執(zhí)行。

Serverless配置

登錄PolarDB控制臺。在設(shè)置Serverless配置參數(shù)頁面，將單節(jié)點資源彈升上限設(shè)置為32，單節(jié)點彈升資源下限設(shè)置為1，只讀節(jié)點個數(shù)擴(kuò)展上限設(shè)置為7，只讀節(jié)點個數(shù)擴(kuò)展下限設(shè)置為0。設(shè)置Serverless配置參數(shù)詳細(xì)操作步驟請參見設(shè)置Serverless集群資源擴(kuò)縮策略。

Sysbench壓測命令

Sysbench壓測使用的命令如下，該測試使用oltp_read_write模式。

-- threads不同的線程數(shù)可以構(gòu)造不同的負(fù)載，以xxx為例
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=http://xxxx.rwlb.rds.aliyuncs.com --mysql-port=3306 --mysql-user=xxxx --mysql-password=xxxx --mysql-db=sbtest --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=128 --time=12000 run

其中，mysql-host的值需配置為集群地址，并配置--db-ps-mode=disable以確保所有的事務(wù)SQL以原始SQL語句的方式執(zhí)行。

確保主節(jié)點在之前的測試結(jié)束后已經(jīng)降至1 PCU，重新發(fā)起和擴(kuò)縮測試一樣的Sysbench壓力，即使用128個線程進(jìn)行oltp_read_write壓測。

測試結(jié)果

登錄PolarDB控制臺。在目標(biāo)集群的基本信息頁面的數(shù)據(jù)庫節(jié)點區(qū)域，可以看到，在壓力執(zhí)行一段時間后，系統(tǒng)開始自動創(chuàng)建只讀節(jié)點。

一段時間后進(jìn)入穩(wěn)定狀態(tài)，系統(tǒng)不再繼續(xù)創(chuàng)建只讀節(jié)點。

進(jìn)入穩(wěn)定狀態(tài)后，Sysbench的輸出如下：

對比之前單節(jié)點同壓力的測試結(jié)果，性能略有下降，QPS從34~35w下降到32~33w。

查看性能監(jiān)控中的Serverless監(jiān)控指標(biāo)項，可以看到類似如下的曲線，查看性能監(jiān)控指標(biāo)的詳細(xì)操作步驟請參見查看性能監(jiān)控指標(biāo)。

主節(jié)點很快彈升至32 PCU，只讀節(jié)點創(chuàng)建出來后，開始承擔(dān)一部分讀負(fù)載，主節(jié)點CPU使用率下降，PCU縮容。由于彈出的只讀節(jié)點的CPU使用率沒有超過彈性閾值的80%，因此，在該壓力下只會擴(kuò)容一個只讀節(jié)點。

將并發(fā)數(shù)量增大到2倍，停止Sysbench壓力，立即執(zhí)行256個線程的并發(fā)oltp_read_write。等待一段時間，會發(fā)現(xiàn)系統(tǒng)開始大量彈出新的只讀節(jié)點。

同時查看Sysbench的輸出，oltp_read_write的性能也有大幅提升，QPS從32~33w上升至44~46w，從QPS上已經(jīng)突破了單節(jié)點彈性測試的最大吞吐量。這說明成功驗證了Serverless scale-out的效果。

查看Serverless監(jiān)控信息，會看到存在多個只讀節(jié)點的曲線。且當(dāng)新的只讀節(jié)點彈出后，先前的節(jié)點就會逐步降低負(fù)載，最終達(dá)到一個大致的均衡，這說明Proxy成功將負(fù)載均衡到新彈出的只讀節(jié)點中。由于目前Serverless為了避免頻繁的規(guī)格震蕩，彈升彈降的閾值是一個大區(qū)間，同時降配對性能也存在一定的負(fù)反饋，因此Proxy很難做到100%的均衡，先降配的PCU最終值會偏低。

運行一段時間后，停止Sysbench，PolarDB的計算節(jié)點首先會自動縮容，大約1~2分鐘會逐步降至1 PCU。壓力停止之后，只讀節(jié)點的CPU使用率會立刻降低，而主節(jié)點還需要執(zhí)行purge undo操作，CPU消耗會持續(xù)一小段時間，最終降到1 PCU。如果等待較長一段時間，新增的只讀節(jié)點也會在15~20分鐘內(nèi)逐步回收。為了避免只讀節(jié)點頻繁的彈性震蕩，Serverless沒有選擇立即回收無負(fù)載的只讀節(jié)點。