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