生產數據庫架構改造方案樣本(7頁).doc
下載文檔
上傳人:t***
編號:904260
2024-03-22
5頁
27KB
1、生產數據庫性能優化方案(草稿)1. 背景生產數據庫上線一段時間后由于數據量遠不不大于預期,導致數據庫性能低下而影響正常業務,故需要對數據庫進行性能優化。2. 現狀當前數據庫構造如下圖所示:圖2-1 系統構造示意圖上游三個數據源通過DI工具以定期任務方式將上游數據抽取到基本數據庫中(紅色某些),從基本庫到下游目的庫則是通過顧客操作應用程序將基本數據庫中數據調度到目的數據庫中。依照當前對數據量記錄基本庫約為400GB+數據總量。當前基本數據庫性能低下,重要體現于定期抽取任務執行時間過長,任務間時間間隔變短;應用執行數據調度時間過長,導致應用長時間處在無響應狀態。3. 分析基本數據庫獲取上游數據時,2、數據傳播量較大,數據庫寫操作頻繁,操作系統層體現于數據文獻所在磁盤寫IO高,并持續時間長。由于基本庫放數據到下游數據庫是人為操作,數據庫讀操作頻繁,操作系統層體現于數據文獻所在磁盤讀IO高,且經常會與DI定期任務同步執行,通過系統監控發現磁盤浮現大量IO等待狀態。圖 3-1 磁盤IO狀態圖 3-2 磁盤等待狀態由于基本庫保存原始數據并不對數據進行解決,因此CPU消耗很低,從監控看CPU不視為性能瓶頸點。圖 3-3 CPU使用率從以上分析可以判斷數據庫操作性能低下重要在高磁盤IO時導致IO掙用較大導致拖慢整體性能。故本次優化將重點放在解決磁盤IO掙用問題和提高磁盤IOPS上。4. 優化方案本著應3、用層變動最小原則,為解決基本庫磁盤IO性能低下問題,咱們將從三個方面著手進行,即:優化數據庫物理架構、優化DI任務執行時間和優化數據庫數據文獻所在Path磁盤VG構造。4.1. 優化數據庫物理架構依照基本庫業務特點,這里將對基本庫讀寫操作進行分離(即:讀、寫分離)。這樣做好處在于可以最大限度規避數據庫讀、寫同步操作所帶來磁盤IO掙用問題。調節后架構如下圖:數據庫采用主/從模式,使用binlog復制方式實現數據同步。由于考慮到大數據量復制也許帶來同步延遲問題,實現時需要注意優化復制線程參數。4.2. 優化DI任務執行時間為了避免多任務同步寫一種數據庫產生磁盤寫IO過高問題,需要對每一種DI任務執4、行時間進行估算,并依照磁盤性能合理編排任務并行度。同步還需要考慮數據單位時間內數據增長量對任務執行時間影響,避免由于數據量增長延長任務執行時間而導致任務并行執行。4.3. 優化磁盤VG提高磁盤IOPS最有效辦法就是增長通過增長物理磁盤數量并實現條帶化來提高整體IOPS。但隨之帶來硬件投資成本也會增長。這里咱們可以通過將既有磁盤更換成等容量小磁盤,目是為了增長磁盤數量從而提高整體磁盤IOPS性能。如:當前一塊磁盤容量為600GB,咱們可以將其拆解成6塊100GB Raid5磁盤或者12塊50GB Raid5磁盤進行VG條帶化解決。5. 實現5.1. 資源規劃硬件資源: 服務器2臺 數據磁盤12塊5、50GB Raid5磁盤(每臺服務器)軟件資源: CentOS 7.1 x86_64 (mini installed) MySQL 5.7 x86_645.2. 磁盤配備 分別將兩臺服務器各12塊Raid5磁盤初始化并創立VG。在創立LV時特別注意要制定LV所跨PV數量從而實現VG條帶化。 指定磁盤文獻系統為xfs。5.3. 數據庫布置配備 安裝MySQL數據庫并配備兩臺服務器主從模式,將從庫定義為Read_only模式。 配備binlog復制線程數。 優化數據庫內存模型。 導入數據5.4. 應用配備將用于數據調度應用程序數據源從本來數據庫服務器IP地址改為只讀數據庫服務器IP地址。6. 測試實行完畢后為保證最后優化效果,將對系統各個核心環節進行性能測試。測試將分為如下三個階段。6.1. 磁盤性能測試VG創立好后,保證磁盤可寫前提下使用dd命令對磁盤讀、寫分別進行性能測試。讀、寫測試將各進行5次從而選出最適當磁盤塊大小。使用10GB文獻大小,每次創立塊大小分別為4k、8k、16k、32k和64k,并記錄每次測試時間成果。6.2. 數據庫性能測試數據庫性能測試可以使用tpcc-mysql等其她第三方性能測試工具進行,并生成測試報告。6.3. 業務測試最后在實際業務中測試DI運營時間和數據調度響應時間,通過模仿真是業務操作對系統性能進行測試評估。