2022年2月21日20:00點

正在項目現場支持的我突然接到客戶C經理的電話，本以為是溝通確認下一次常規數據庫運維巡檢的時間，但電話那頭傳來的消息卻令人不安。C經理是X企業CRM系統的業務管理人員，X企業CRM系統（簡稱X項目）采用了金倉KingbaseES V8R6一主一備讀寫分離集群架構，業務系統自2021年1月上線以來，一直運行穩定，從未出過差錯。但自從上周X企業陸續上線了一些新的業務模塊后，飛速增長的業務需求使得業務高峰期集群壓力急劇增大，業務訪問效率大幅降低，業務高峰期甚至出現了訪問失敗的現象！對于X企業而言，CRM系統是業務的橋梁。訪問失敗等問題如不能及時解決，將給公司帶來難以估量的損失。因此，C經理希望我盡快趕赴現場支持，定位問題并優化系統。情況緊急，我當即將手上的工作交接給其他同事，著手項目支援的前期準備工作，并通知同事Z次日一起去現場支持。

2022年2月22日早8點

速度 | 分析利器，迅速定位

晨光熹微，我和Z抵達現場，在與C經理就系統現狀簡單溝通交流之后,就迅速和其他業務開發人員、運維人員一起定位問題。根據業務人員反饋，上周陸續上線的這些業務模塊主要以信息查詢為主，新的業務模塊投入使用后，在業務高峰期間并發的訪問量非常高，集群主機的CPU在業務高峰期的負載峰值也在不斷攀升（主機節點CPU負載經常達到90%以上），導致系統訪問性能下降，嚴重影響了業務的正常訪問。在收集了各業務層反應的問題、初步了解系統性能下降的大致原因后，我們憑借多年來的現場支持經驗，決定借助KingbaseES性能分析利器KWR，定位具體的性能問題。?

性能分析利器??Kingbase Auto WorkloadRepertories

TIPS：KWR是KingbaseES自動負載信息庫（Kingbase Auto Workload Repertories），它通過周期性自動記錄性能統計相關的快照，分析出KES的操作系統運行環境、數據庫時間組成、等待事件和TOP SQL等性能指標，為數據庫性能調優提供指導。

鑒于該項目在集群部署后和業務上線之初就已經完成了KWR工具的配置，此次可以直接運行KWR工具，快速獲取KWR分析報告。

步驟1：數據庫主機業務負載分析通過對KWR報告中DB time的分析，我們了解到了當前數據庫的負載情況：DB time =CPU time + Wait time（非空閑等待，非后臺進程）KWR報告顯示，此時采樣期間的DB time遠大于Elasped的時間，說明此時數據庫的負載比較大。

KWR報告CPU time分析

KWR報告CPU time分析?并且通過系統命令檢測到當前高峰期cpu的負載確實達到了百分之90以上。

業務高峰期主機節點CPU壓力?鑒于此，我們決定進一步通過Wait Events、TopSQL來確定DB time的具體消耗。

步驟2：統計和分析高峰期的SQL

通過KWR，對在業務高峰期間影響數據庫性能的SQL進行統計和分析，找出業務高峰期引起數據庫性能下降的具體SQL語句。

TOP SQL信息

獲取的KWR報告中顯示，消耗CPU資源較多的SQL多為Select查詢語句。此外，我們還發現這些SQL語句結構并不復雜，通過對一些慢查詢的SQL執行計劃分析，絕大部分SQL的執行計劃都比較合理，這些SQL在業務低峰時間段測試，其查詢響應時間都是毫秒級，基本排除SQL語句編寫較差引起慢查詢，從而導致的性能問題。?

小結

通過KWR的各種分析，初步結論為：業務峰值期間CPU負載高，是近期業務模塊的并發訪問量急劇增加所導致。目前一主一備的兩個節點，主機已經無法承擔當前的業務對數據庫的訪問壓力，需要對數據庫集群主機進行擴容。

安全 | 全面測試，保障運行

集群擴容方案分析

問題定位清晰之后，接下來就是和業務組討論集群擴容的具體方式。

集群擴容方式

一般而言，集群擴容可采用兩種方式：

垂直擴容/Scale up：對于物理主機來講就是提升單臺主機的硬件配置（CPU、Memory、Disk等）。

水平擴展/Scale out：通過添加節點擴展集群的負載能力。

TIPS：垂直擴容可以采取主備切換的方式，先對備庫進行硬件升級，然后做主備切換，再升級原主庫主機的硬件，客戶端通過集群VIP地址訪問數據庫，不會影響業務的正常訪問。但對于物理主機來說，CPU和Memory等資源都存在最大容量限制，超過限制就無法再提升其配置和性能。

水平擴容可以通過增加主機的方式來動態適應業務的需求，尤其是對“寫少讀多”的業務。理論上水平擴容可以無限擴容，解決了垂直擴容的限制問題

KingbaseES V8R6讀寫分離集群通過jdbc驅動對客戶端的應用進行判斷，并遵守相應分發原則來執行讀寫分離。水平擴容在增加了新的備用節點后，可以將更多對數據庫只讀的壓力分擔到多個備庫節點上。

本次項目上線的業務，其數據庫訪問多以Select查詢為主，由于集群配置了讀寫分離，對于Select的查詢可以通過更多的只讀節點（備庫）進行分擔，并且添加新節點都是在線方式，不會影響業務的正常運行。綜合前面對業務特點的分析，顯而易見，對于當前的X項目，在線水平擴容是最佳選擇。即使未來X企業發展戰略發生變化，業務模塊訪問量下降，還可以在線縮容，縮減集群節點主機的數量并移作他用，不會造成任何資源的浪費。

因此，通過水平擴展增加備庫節點的方式來提升此集群的負載能力，解決性能瓶頸，從 經濟 效益和技術可行性來看，都是一個比較好的方案。水平擴容后的集群架構，將從原來的一主一備集群架構擴展為一主兩備集群架構，通過新增的備庫節點，分擔更多的只讀查詢，分擔集群的負載壓力。

水平擴容后的讀寫分離的集群架構

在線擴容操作方式

KingbaseES V8R6讀寫分離集群在線水平擴容有兩種方式，通過圖形化的工具在線添加新節點，或通過“repmgr standby clone”工具以命令行的方式執行新節點添加。

圖形化擴容和命令行擴容的對比表

對于生產環境來講，如果數據庫數據量大，通過圖形化的工具在線添加新節點會增加主庫的網絡I/O壓力。所以我們此次采用字符命令行的方式部署擴容，在降低主庫網絡I/O壓力的同時，對新節點的克隆進行定制（如指定數據存儲路徑、從指定的節點克隆等）。確定了擴容方案后，接下來就需要確定等待新服務器到位期間的保障方案，以及測試環境模擬擴容。?

2022年2月22日20:00點

保障業務運行的臨時方案

然而，擴容方案驗證和硬件采購還需要兩周的時間。如何降低系統負荷，讓用戶業務系統安全度過這兩周的空窗期，是當下急需考慮的問題。

對于降低系統負荷，通常有以下三種方式：

1）業務的性能優化，包括應用層面業務邏輯的優化，以及數據庫層面SQL運行效率的優化；

2）暫停部分非必要的應用，確保關鍵應用運行；

3）調整批處理定時任務運行時段，錯峰運行。

方案1，對于SQL性能的優化。由于前期我們已經幫客戶進行了大量的優化工作，從KWR報告的TOPSQL看，目前已無優化的余地。而業務層面的邏輯優化，需要涉及應用的大改造，遠水解不了近渴。方案2，暫停部分非必要的應用。C經理將此方案匯報給上級領導后，遭到否決，因為用戶要求所有業務必須可訪問。

那么，只有第三種方案可選了。刻不容緩，我們緊急查看了服務器資源利用率的歷史曲線圖，發現業務的運行高峰在早上9點到晚上21點之間，而其他時間CPU利用率不到白天高峰的一半。如果部分批處理定時任務能夠調整到晚上運行，就可以降低白天的CPU負荷。我們立即梳理了主節點上操作系統與數據庫定時任務，與客戶逐個分析每個任務的關鍵性。幸運的是客戶與業務部門溝通后，答應臨時降低部分定時任務的白天運行頻率，轉而在晚上運行。事不宜遲，我們立即調整定時任務，觀察實際效果。確認白天時段總體CPU 有5%左右的下降，CPU曲線也更平滑了，調整取得了立竿見影的效果。又是一個通宵達旦，但業務系統運行暫時得到了保障，令我們暫緩了一口氣。接下來還要繼續加緊驗證測試擴容方案，畢竟調整批處理定時任務只是權宜之計。

2022年2月24日8:00點

集群水平擴容業務模擬壓測

為了確定最終方案的可行性，我們先在測試環境下進行集群的擴容測試。在當前一主一備的測試環境下，采用命令行方式擴容，增加一個新的備庫節點。擴容前后分別通過jmeter工具模擬業務對集群壓測，以驗證方案的正確性。測試環境使用命令行擴容，擴容完成總共耗時不到三小時。擴容期間，監控集群運行正常，業務模塊可以正常訪問。根據回退測試，在擴容期間，在線刪除新的備庫節點對原集群運行不造成任何影響。通過jmeter工具對集群進行性能壓測，主要采用Select查詢語句測試數據庫負載，為了能更好的體現測試效果，我們采用了簡單的SQL查詢語句，分別在不同線程數下，對數據庫QPS的測試。結果顯示，測試環境的集群擴容為一主兩備的架構后，通過新的備庫節點分擔只讀查詢的訪問，QPS相對于擴容前得到了有效的提升，完全滿足了當前業務的需求。

測試完成后，我們便與C經理一起向領導匯報了包含臨時應急處置措施和擴容壓測的完整解決方案。X企業相關領導對我們的方案和效率表示高度認可，最終拍板采用集群水平擴展的方案，來解決當前業務增長產生的性能問題。在原來一主一備的基礎上增加一個新的備庫節點，構建一主二備的集群架構。接下來就是等新的服務器到場后，在生產環境上實施在線擴容方案。

2022年3月11日8:00點

可靠 | 在線擴容，專業服務

擴容服務器的硬件網絡環境準備就緒，萬事俱備。生成環境擴容操作需要有一定經驗的技術人員來完成，所以由我親自操作，同事Z從旁監控，雙重保險。為減輕對X公司當前業務的影響，按照原有的計劃于周六的凌晨12點，在業務低峰期正式開始在線擴容。白天繼續做一些環境準備工作。

2022年3月12日0:00點

凌晨12點準時開始在線擴容。做好數據備份工作后，正式開始操作擴容。

操作步驟如下：

1）配置新節點的系統環境（如網絡、ssh互信、內核資源管理、防火墻配置等）。

2）從已有的節點（備庫）上傳集群相關目錄（除了data目錄）外，到新的節點。

3）修改新備節點下的repmgr.conf配置，指定節點ip、節點名稱、數據存儲路徑等。

4）在原主庫下創建復制槽（replication slots）。

5）在新的備節點執行備庫克隆(-h：指定已有備庫節點的ip)

6）啟動新備庫數據庫服務，注冊新的備庫到集群完成克隆。?

此次生產數據600G以上，完成在線擴容實施共花費兩個半個小時。在擴容期間，監控生產業務的運行，沒有發現生產業務訪問和業務的故障問題。凌晨2點半，本次集群在線擴容操作順利完成。擴容結束后，系統運維人員對業務系統的所有模塊進行了功能測試，所有業務模塊運轉正常。功能全部正常，接下來就是等待業務高峰期的系統性能檢驗。轉眼凌晨5點半，但我們困意全無。為保險起見，我還是決定對擴容后集群環境先做一個性能壓力測試。再次通過jmeter工具對集群進行性能壓測，測試結果顯示，在線擴容構建一主兩備的集群架構后，訪問性能得到極大的提升，一主兩備的架構完全可以承載當前及未來一段時間的業務壓力。旭日東升，壓測完成后已經早上7點，我們正式下班，準備接受下周一正式業務高峰期的檢驗。?

2022年3月14日9:00點

星期一到了，我們在高峰期間進行性能監控，集群主機節點CPU的負載一直都在低位運行，完全達到了擴容前的預期結果，業務訪問的效率得到了有效的提升。本次KingbaseES讀寫分離集群在線水平擴容圓滿結束。項目擴容順利完成，終于如釋重負。激動并欣慰，作為金倉人，為國產化信息事業建設又出了一份力。C經理代表業務組對我們金倉數據庫的技術服務響應速度和解決問題的能力，表示充分肯定和感謝。保障客戶的業務系統數據庫正常運行是我們的責任，以后需要再接再厲，為數據庫國產化事業添磚加瓦。

結語

本次項目依靠金倉的性能分析利器KWR、穩定運行的KingbaseES集群，以及專業的金倉技術服務團隊，通過KWR分析能快速定位到問題，金倉KingbaseES數據庫集群支持在線平滑擴容，所以經過金倉技術工程師分析、測試和操作，迅速解決了業務運行性能瓶頸問題。KingbaseES V8R6讀寫分離集群的在線擴容功能，可以實現在線平滑擴容，在不影響企業業務的前提下快速解決企業面臨的性能瓶頸問題。并且在企業前期業務需求較少的情況下，只需要投入少量資金，構建最基本集群架構，以滿足當前的業務需求，在后期業務需求增大的情況下，只需要按需增加集群的節點，不會造成前期資金大量投入的浪費，提升企業的投入產出比，獲取更好的經濟效益。

金倉數據庫專業的技術服務團隊及時響應客戶的在線擴容需求，為您提供速度、安全、可靠的技術服務，堅持7*24小時為客戶保駕護航。