2022年2月21日20:00點(diǎn)
正在項(xiàng)目現(xiàn)場支持的我突然接到客戶C經(jīng)理的電話，本以為是溝通確認(rèn)下一次常規(guī)數(shù)據(jù)庫運(yùn)維巡檢的時間，但電話那頭傳來的消息卻令人不安。C經(jīng)理是X企業(yè)CRM系統(tǒng)的業(yè)務(wù)管理人員，X企業(yè)CRM系統(tǒng)(簡稱X項(xiàng)目)采用了金倉KingbaseES V8R6一主一備讀寫分離集群架構(gòu)，業(yè)務(wù)系統(tǒng)自2021年1月上線以來，一直運(yùn)行穩(wěn)定，從未出過差錯。但自從上周X企業(yè)陸續(xù)上線了一些新的業(yè)務(wù)模塊后，飛速增長的業(yè)務(wù)需求使得業(yè)務(wù)高峰期集群壓力急劇增大，業(yè)務(wù)訪問效率大幅降低，業(yè)務(wù)高峰期甚至出現(xiàn)了訪問失敗的現(xiàn)象!對于X企業(yè)而言，CRM系統(tǒng)是業(yè)務(wù)的橋梁。訪問失敗等問題如不能及時解決，將給公司帶來難以估量的損失。因此，C經(jīng)理希望我盡快趕赴現(xiàn)場支持，定位問題并優(yōu)化系統(tǒng)。情況緊急，我當(dāng)即將手上的工作交接給其他同事，著手項(xiàng)目支援的前期準(zhǔn)備工作，并通知同事Z次日一起去現(xiàn)場支持。
2022年2月22日早8點(diǎn)
速度 | 分析利器，迅速定位
晨光熹微，我和Z抵達(dá)現(xiàn)場，在與C經(jīng)理就系統(tǒng)現(xiàn)狀簡單溝通交流之后,就迅速和其他業(yè)務(wù)開發(fā)人員、運(yùn)維人員一起定位問題。根據(jù)業(yè)務(wù)人員反饋，上周陸續(xù)上線的這些業(yè)務(wù)模塊主要以信息查詢?yōu)橹鳎碌臉I(yè)務(wù)模塊投入使用后，在業(yè)務(wù)高峰期間并發(fā)的訪問量非常高，集群主機(jī)的CPU在業(yè)務(wù)高峰期的負(fù)載峰值也在不斷攀升(主機(jī)節(jié)點(diǎn)CPU負(fù)載經(jīng)常達(dá)到90%以上)，導(dǎo)致系統(tǒng)訪問性能下降，嚴(yán)重影響了業(yè)務(wù)的正常訪問。在收集了各業(yè)務(wù)層反應(yīng)的問題、初步了解系統(tǒng)性能下降的大致原因后，我們憑借多年來的現(xiàn)場支持經(jīng)驗(yàn)，決定借助KingbaseES性能分析利器KWR，定位具體的性能問題。
性能分析利器Kingbase Auto WorkloadRepertories
TIPS：KWR是KingbaseES自動負(fù)載信息庫(Kingbase Auto Workload Repertories)，它通過周期性自動記錄性能統(tǒng)計(jì)相關(guān)的快照，分析出KES的操作系統(tǒng)運(yùn)行環(huán)境、數(shù)據(jù)庫時間組成、等待事件和TOP SQL等性能指標(biāo)，為數(shù)據(jù)庫性能調(diào)優(yōu)提供指導(dǎo)。
鑒于該項(xiàng)目在集群部署后和業(yè)務(wù)上線之初就已經(jīng)完成了KWR工具的配置，此次可以直接運(yùn)行KWR工具，快速獲取KWR分析報告。
步驟1：數(shù)據(jù)庫主機(jī)業(yè)務(wù)負(fù)載分析通過對KWR報告中DB time的分析，我們了解到了當(dāng)前數(shù)據(jù)庫的負(fù)載情況：DB time =CPU time + Wait time(非空閑等待，非后臺進(jìn)程)KWR報告顯示，此時采樣期間的DB time遠(yuǎn)大于Elasped的時間，說明此時數(shù)據(jù)庫的負(fù)載比較大。
KWR報告CPU time分析
KWR報告CPU time分析并且通過系統(tǒng)命令檢測到當(dāng)前高峰期cpu的負(fù)載確實(shí)達(dá)到了百分之90以上。
業(yè)務(wù)高峰期主機(jī)節(jié)點(diǎn)CPU壓力鑒于此，我們決定進(jìn)一步通過Wait Events、TopSQL來確定DB time的具體消耗。
步驟2：統(tǒng)計(jì)和分析高峰期的SQL
通過KWR，對在業(yè)務(wù)高峰期間影響數(shù)據(jù)庫性能的SQL進(jìn)行統(tǒng)計(jì)和分析，找出業(yè)務(wù)高峰期引起數(shù)據(jù)庫性能下降的具體SQL語句。
TOP SQL信息
獲取的KWR報告中顯示，消耗CPU資源較多的SQL多為Select查詢語句。此外，我們還發(fā)現(xiàn)這些SQL語句結(jié)構(gòu)并不復(fù)雜，通過對一些慢查詢的SQL執(zhí)行計(jì)劃分析，絕大部分SQL的執(zhí)行計(jì)劃都比較合理，這些SQL在業(yè)務(wù)低峰時間段測試，其查詢響應(yīng)時間都是毫秒級，基本排除SQL語句編寫較差引起慢查詢，從而導(dǎo)致的性能問題。
小結(jié)
通過KWR的各種分析，初步結(jié)論為：業(yè)務(wù)峰值期間CPU負(fù)載高，是近期業(yè)務(wù)模塊的并發(fā)訪問量急劇增加所導(dǎo)致。目前一主一備的兩個節(jié)點(diǎn)，主機(jī)已經(jīng)無法承擔(dān)當(dāng)前的業(yè)務(wù)對數(shù)據(jù)庫的訪問壓力，需要對數(shù)據(jù)庫集群主機(jī)進(jìn)行擴(kuò)容。
安全 | 全面測試，保障運(yùn)行
集群擴(kuò)容方案分析
問題定位清晰之后，接下來就是和業(yè)務(wù)組討論集群擴(kuò)容的具體方式。
集群擴(kuò)容方式
一般而言，集群擴(kuò)容可采用兩種方式：
垂直擴(kuò)容/Scale up：對于物理主機(jī)來講就是提升單臺主機(jī)的硬件配置(CPU、Memory、Disk等)。
水平擴(kuò)展/Scale out：通過添加節(jié)點(diǎn)擴(kuò)展集群的負(fù)載能力。
TIPS：垂直擴(kuò)容可以采取主備切換的方式，先對備庫進(jìn)行硬件升級，然后做主備切換，再升級原主庫主機(jī)的硬件，客戶端通過集群VIP地址訪問數(shù)據(jù)庫，不會影響業(yè)務(wù)的正常訪問。但對于物理主機(jī)來說，CPU和Memory等資源都存在最大容量限制，超過限制就無法再提升其配置和性能。
水平擴(kuò)容可以通過增加主機(jī)的方式來動態(tài)適應(yīng)業(yè)務(wù)的需求，尤其是對“寫少讀多”的業(yè)務(wù)。理論上水平擴(kuò)容可以無限擴(kuò)容，解決了垂直擴(kuò)容的限制問題
KingbaseES V8R6讀寫分離集群通過jdbc驅(qū)動對客戶端的應(yīng)用進(jìn)行判斷，并遵守相應(yīng)分發(fā)原則來執(zhí)行讀寫分離。水平擴(kuò)容在增加了新的備用節(jié)點(diǎn)后，可以將更多對數(shù)據(jù)庫只讀的壓力分擔(dān)到多個備庫節(jié)點(diǎn)上。
本次項(xiàng)目上線的業(yè)務(wù)，其數(shù)據(jù)庫訪問多以Select查詢?yōu)橹?，由于集群配置了讀寫分離，對于Select的查詢可以通過更多的只讀節(jié)點(diǎn)(備庫)進(jìn)行分擔(dān)，并且添加新節(jié)點(diǎn)都是在線方式，不會影響業(yè)務(wù)的正常運(yùn)行。綜合前面對業(yè)務(wù)特點(diǎn)的分析，顯而易見，對于當(dāng)前的X項(xiàng)目，在線水平擴(kuò)容是最佳選擇。即使未來X企業(yè)發(fā)展戰(zhàn)略發(fā)生變化，業(yè)務(wù)模塊訪問量下降，還可以在線縮容，縮減集群節(jié)點(diǎn)主機(jī)的數(shù)量并移作他用，不會造成任何資源的浪費(fèi)。
因此，通過水平擴(kuò)展增加備庫節(jié)點(diǎn)的方式來提升此集群的負(fù)載能力，解決性能瓶頸，從經(jīng)濟(jì)效益和技術(shù)可行性來看，都是一個比較好的方案。水平擴(kuò)容后的集群架構(gòu)，將從原來的一主一備集群架構(gòu)擴(kuò)展為一主兩備集群架構(gòu)，通過新增的備庫節(jié)點(diǎn)，分擔(dān)更多的只讀查詢，分擔(dān)集群的負(fù)載壓力。
水平擴(kuò)容后的讀寫分離的集群架構(gòu)
在線擴(kuò)容操作方式
KingbaseES V8R6讀寫分離集群在線水平擴(kuò)容有兩種方式，通過圖形化的工具在線添加新節(jié)點(diǎn)，或通過“repmgr standby clone”工具以命令行的方式執(zhí)行新節(jié)點(diǎn)添加。
圖形化擴(kuò)容和命令行擴(kuò)容的對比表
對于生產(chǎn)環(huán)境來講，如果數(shù)據(jù)庫數(shù)據(jù)量大，通過圖形化的工具在線添加新節(jié)點(diǎn)會增加主庫的網(wǎng)絡(luò)I/O壓力。所以我們此次采用字符命令行的方式部署擴(kuò)容，在降低主庫網(wǎng)絡(luò)I/O壓力的同時，對新節(jié)點(diǎn)的克隆進(jìn)行定制(如指定數(shù)據(jù)存儲路徑、從指定的節(jié)點(diǎn)克隆等)。確定了擴(kuò)容方案后，接下來就需要確定等待新服務(wù)器到位期間的保障方案，以及測試環(huán)境模擬擴(kuò)容。
2022年2月22日20:00點(diǎn)
保障業(yè)務(wù)運(yùn)行的臨時方案
然而，擴(kuò)容方案驗(yàn)證和硬件采購還需要兩周的時間。如何降低系統(tǒng)負(fù)荷，讓用戶業(yè)務(wù)系統(tǒng)安全度過這兩周的空窗期，是當(dāng)下急需考慮的問題。
對于降低系統(tǒng)負(fù)荷，通常有以下三種方式：
1)業(yè)務(wù)的性能優(yōu)化，包括應(yīng)用層面業(yè)務(wù)邏輯的優(yōu)化，以及數(shù)據(jù)庫層面SQL運(yùn)行效率的優(yōu)化;
2)暫停部分非必要的應(yīng)用，確保關(guān)鍵應(yīng)用運(yùn)行;
3)調(diào)整批處理定時任務(wù)運(yùn)行時段，錯峰運(yùn)行。
方案1，對于SQL性能的優(yōu)化。由于前期我們已經(jīng)幫客戶進(jìn)行了大量的優(yōu)化工作，從KWR報告的TOPSQL看，目前已無優(yōu)化的余地。而業(yè)務(wù)層面的邏輯優(yōu)化，需要涉及應(yīng)用的大改造，遠(yuǎn)水解不了近渴。方案2，暫停部分非必要的應(yīng)用。C經(jīng)理將此方案匯報給上級領(lǐng)導(dǎo)后，遭到否決，因?yàn)橛脩粢笏袠I(yè)務(wù)必須可訪問。
那么，只有第三種方案可選了。刻不容緩，我們緊急查看了服務(wù)器資源利用率的歷史曲線圖，發(fā)現(xiàn)業(yè)務(wù)的運(yùn)行高峰在早上9點(diǎn)到晚上21點(diǎn)之間，而其他時間CPU利用率不到白天高峰的一半。如果部分批處理定時任務(wù)能夠調(diào)整到晚上運(yùn)行，就可以降低白天的CPU負(fù)荷。我們立即梳理了主節(jié)點(diǎn)上操作系統(tǒng)與數(shù)據(jù)庫定時任務(wù)，與客戶逐個分析每個任務(wù)的關(guān)鍵性。幸運(yùn)的是客戶與業(yè)務(wù)部門溝通后，答應(yīng)臨時降低部分定時任務(wù)的白天運(yùn)行頻率，轉(zhuǎn)而在晚上運(yùn)行。事不宜遲，我們立即調(diào)整定時任務(wù)，觀察實(shí)際效果。確認(rèn)白天時段總體CPU 有5%左右的下降，CPU曲線也更平滑了，調(diào)整取得了立竿見影的效果。又是一個通宵達(dá)旦，但業(yè)務(wù)系統(tǒng)運(yùn)行暫時得到了保障，令我們暫緩了一口氣。接下來還要繼續(xù)加緊驗(yàn)證測試擴(kuò)容方案，畢竟調(diào)整批處理定時任務(wù)只是權(quán)宜之計(jì)。
2022年2月24日8:00點(diǎn)
集群水平擴(kuò)容業(yè)務(wù)模擬壓測
為了確定最終方案的可行性，我們先在測試環(huán)境下進(jìn)行集群的擴(kuò)容測試。在當(dāng)前一主一備的測試環(huán)境下，采用命令行方式擴(kuò)容，增加一個新的備庫節(jié)點(diǎn)。擴(kuò)容前后分別通過jmeter工具模擬業(yè)務(wù)對集群壓測，以驗(yàn)證方案的正確性。測試環(huán)境使用命令行擴(kuò)容，擴(kuò)容完成總共耗時不到三小時。擴(kuò)容期間，監(jiān)控集群運(yùn)行正常，業(yè)務(wù)模塊可以正常訪問。根據(jù)回退測試，在擴(kuò)容期間，在線刪除新的備庫節(jié)點(diǎn)對原集群運(yùn)行不造成任何影響。通過jmeter工具對集群進(jìn)行性能壓測，主要采用Select查詢語句測試數(shù)據(jù)庫負(fù)載，為了能更好的體現(xiàn)測試效果，我們采用了簡單的SQL查詢語句，分別在不同線程數(shù)下，對數(shù)據(jù)庫QPS的測試。結(jié)果顯示，測試環(huán)境的集群擴(kuò)容為一主兩備的架構(gòu)后，通過新的備庫節(jié)點(diǎn)分擔(dān)只讀查詢的訪問，QPS相對于擴(kuò)容前得到了有效的提升，完全滿足了當(dāng)前業(yè)務(wù)的需求。
測試完成后，我們便與C經(jīng)理一起向領(lǐng)導(dǎo)匯報了包含臨時應(yīng)急處置措施和擴(kuò)容壓測的完整解決方案。X企業(yè)相關(guān)領(lǐng)導(dǎo)對我們的方案和效率表示高度認(rèn)可，最終拍板采用集群水平擴(kuò)展的方案，來解決當(dāng)前業(yè)務(wù)增長產(chǎn)生的性能問題。在原來一主一備的基礎(chǔ)上增加一個新的備庫節(jié)點(diǎn)，構(gòu)建一主二備的集群架構(gòu)。接下來就是等新的服務(wù)器到場后，在生產(chǎn)環(huán)境上實(shí)施在線擴(kuò)容方案。
2022年3月11日8:00點(diǎn)
可靠 | 在線擴(kuò)容，專業(yè)服務(wù)
擴(kuò)容服務(wù)器的硬件網(wǎng)絡(luò)環(huán)境準(zhǔn)備就緒，萬事俱備。生成環(huán)境擴(kuò)容操作需要有一定經(jīng)驗(yàn)的技術(shù)人員來完成，所以由我親自操作，同事Z從旁監(jiān)控，雙重保險。為減輕對X公司當(dāng)前業(yè)務(wù)的影響，按照原有的計(jì)劃于周六的凌晨12點(diǎn)，在業(yè)務(wù)低峰期正式開始在線擴(kuò)容。白天繼續(xù)做一些環(huán)境準(zhǔn)備工作。
2022年3月12日0:00點(diǎn)
凌晨12點(diǎn)準(zhǔn)時開始在線擴(kuò)容。做好數(shù)據(jù)備份工作后，正式開始操作擴(kuò)容。
操作步驟如下：
1)配置新節(jié)點(diǎn)的系統(tǒng)環(huán)境(如網(wǎng)絡(luò)、ssh互信、內(nèi)核資源管理、防火墻配置等)。
2)從已有的節(jié)點(diǎn)(備庫)上傳集群相關(guān)目錄(除了data目錄)外，到新的節(jié)點(diǎn)。
3)修改新備節(jié)點(diǎn)下的repmgr.conf配置，指定節(jié)點(diǎn)ip、節(jié)點(diǎn)名稱、數(shù)據(jù)存儲路徑等。
4)在原主庫下創(chuàng)建復(fù)制槽(replication slots)。
5)在新的備節(jié)點(diǎn)執(zhí)行備庫克隆(-h：指定已有備庫節(jié)點(diǎn)的ip)
6)啟動新備庫數(shù)據(jù)庫服務(wù)，注冊新的備庫到集群完成克隆。
此次生產(chǎn)數(shù)據(jù)600G以上，完成在線擴(kuò)容實(shí)施共花費(fèi)兩個半個小時。在擴(kuò)容期間，監(jiān)控生產(chǎn)業(yè)務(wù)的運(yùn)行，沒有發(fā)現(xiàn)生產(chǎn)業(yè)務(wù)訪問和業(yè)務(wù)的故障問題。凌晨2點(diǎn)半，本次集群在線擴(kuò)容操作順利完成。擴(kuò)容結(jié)束后，系統(tǒng)運(yùn)維人員對業(yè)務(wù)系統(tǒng)的所有模塊進(jìn)行了功能測試，所有業(yè)務(wù)模塊運(yùn)轉(zhuǎn)正常。功能全部正常，接下來就是等待業(yè)務(wù)高峰期的系統(tǒng)性能檢驗(yàn)。轉(zhuǎn)眼凌晨5點(diǎn)半，但我們困意全無。為保險起見，我還是決定對擴(kuò)容后集群環(huán)境先做一個性能壓力測試。再次通過jmeter工具對集群進(jìn)行性能壓測，測試結(jié)果顯示，在線擴(kuò)容構(gòu)建一主兩備的集群架構(gòu)后，訪問性能得到極大的提升，一主兩備的架構(gòu)完全可以承載當(dāng)前及未來一段時間的業(yè)務(wù)壓力。旭日東升，壓測完成后已經(jīng)早上7點(diǎn)，我們正式下班，準(zhǔn)備接受下周一正式業(yè)務(wù)高峰期的檢驗(yàn)。
2022年3月14日9:00點(diǎn)
星期一到了，我們在高峰期間進(jìn)行性能監(jiān)控，集群主機(jī)節(jié)點(diǎn)CPU的負(fù)載一直都在低位運(yùn)行，完全達(dá)到了擴(kuò)容前的預(yù)期結(jié)果，業(yè)務(wù)訪問的效率得到了有效的提升。本次KingbaseES讀寫分離集群在線水平擴(kuò)容圓滿結(jié)束。項(xiàng)目擴(kuò)容順利完成，終于如釋重負(fù)。激動并欣慰，作為金倉人，為國產(chǎn)化信息事業(yè)建設(shè)又出了一份力。C經(jīng)理代表業(yè)務(wù)組對我們金倉數(shù)據(jù)庫的技術(shù)服務(wù)響應(yīng)速度和解決問題的能力，表示充分肯定和感謝。保障客戶的業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫正常運(yùn)行是我們的責(zé)任，以后需要再接再厲，為數(shù)據(jù)庫國產(chǎn)化事業(yè)添磚加瓦。
結(jié)語
本次項(xiàng)目依靠金倉的性能分析利器KWR、穩(wěn)定運(yùn)行的KingbaseES集群，以及專業(yè)的金倉技術(shù)服務(wù)團(tuán)隊(duì)，通過KWR分析能快速定位到問題，金倉KingbaseES數(shù)據(jù)庫集群支持在線平滑擴(kuò)容，所以經(jīng)過金倉技術(shù)工程師分析、測試和操作，迅速解決了業(yè)務(wù)運(yùn)行性能瓶頸問題。KingbaseES V8R6讀寫分離集群的在線擴(kuò)容功能，可以實(shí)現(xiàn)在線平滑擴(kuò)容，在不影響企業(yè)業(yè)務(wù)的前提下快速解決企業(yè)面臨的性能瓶頸問題。并且在企業(yè)前期業(yè)務(wù)需求較少的情況下，只需要投入少量資金，構(gòu)建最基本集群架構(gòu)，以滿足當(dāng)前的業(yè)務(wù)需求，在后期業(yè)務(wù)需求增大的情況下，只需要按需增加集群的節(jié)點(diǎn)，不會造成前期資金大量投入的浪費(fèi)，提升企業(yè)的投入產(chǎn)出比，獲取更好的經(jīng)濟(jì)效益。
金倉數(shù)據(jù)庫專業(yè)的技術(shù)服務(wù)團(tuán)隊(duì)及時響應(yīng)客戶的在線擴(kuò)容需求，為您提供速度、安全、可靠的技術(shù)服務(wù)，堅(jiān)持7*24小時為客戶保駕護(hù)航。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
