高可用數(shù)據庫平臺架構及日常管理經驗介紹整理ppt

1、高可用數(shù)據庫平臺架構 及日常管理經驗介紹 研發(fā)中心研發(fā)中心 邵宗文邵宗文 傳統(tǒng)基礎設施平臺 無法解決擁堵問題，不適合繁華地區(qū)。 高可用的基礎設施平臺 為何需要搭建數(shù)據庫平臺n各大部門自己申請數(shù)據庫服務器，運維成本過高。n操作系統(tǒng)，數(shù)據庫版本不一。n出現(xiàn)突發(fā)熱點，造成數(shù)據庫讀寫訪問巨增，受限于部門數(shù)據庫資源機器，而錯失擴大業(yè)務良機。n缺乏統(tǒng)一的數(shù)據庫服務器性能監(jiān)控和報警。n新項目產品上線數(shù)量過多，單個部門的數(shù)據庫資源無法滿足。n無專門的人進行全局數(shù)據庫各種讀寫操作統(tǒng)計的分析。n存在磁盤故障導致不可訪問，無自動切換的問題。目前新浪數(shù)據庫平臺現(xiàn)狀n多個idc數(shù)據中心nmysql5.0n數(shù)據庫服務幾百

2、臺.(不斷增長中)n約有幾百t的數(shù)據量.（線上+備份存檔）n約有幾百個項目產品使用。n平臺重點產品有：財經，體育，統(tǒng)一通行證，無線wap，讀書，音樂，空間, 通用投票，博客圈，博客雜志，汽車，科技，發(fā)布系統(tǒng)等。 不可避免的故障數(shù)據庫網絡結構簡圖數(shù)據庫平臺的其他好處：n提升全球擴展性，包括新浪香港和北美等都能共享到重要數(shù)據資源，如體育，財經數(shù)據。n讓用戶訪問就近idc，提升服務質量。n很多剛開始的項目可以混用同一個服務器資源。關于一些數(shù)據庫日常管理的經驗介紹n如何去了解應用項目的數(shù)據庫使用情況？n大項目的有效切分方式？n一個庫下多少表比較合適？n長期運行的數(shù)據庫，如何避免表性能下降？n減少慢查詢

3、語句的方法有哪些？n數(shù)據庫服務器負載急劇上升的主要原因？ 不要超過自身運輸能力數(shù)據庫應用項目規(guī)劃和優(yōu)化原則1. 了解自己的應用n應用類型讀多寫少（如體育，讀書），讀寫比例差不多（如音樂），和寫多讀少（如投票，統(tǒng)計）n預計數(shù)據量半年？一年？后續(xù)擴展？ 決定單表還是多表，擴展的方法(hash分表) n預計訪問量多少讀？多少寫？峰值？ com_select,com_update(insert,delete)n實時數(shù)據和非實時數(shù)據哪些必須實時查詢？哪些可以預先準備或可以cache？哪些用于統(tǒng)計匯總？n時間的要求實時性高的項目，如財經，體育，實時性低的項目如博客圈等。 合理分配調度，實現(xiàn)全球快速到達。2

4、.如何對大應用項目切分n保證數(shù)據庫單個實例盡量不要超過150g。n切分盡量多的小實例，一個機器跑7-8個實例，平常load avg不超過1-2，峰值不超過6-7為合理。n分表原則的選擇按時間(財經)按id號hash分(統(tǒng)一通行證)按業(yè)務項目(通用投票)3. 單庫表數(shù)量的限制- 為什么？ - 受文件系統(tǒng)操作限制，文件數(shù)過大需要更多文件句柄，且大目錄操作造成復制、壓縮、備份效率低。 - 打開表占用數(shù)據庫資源（table_cache） 建議一個庫不應超過300-400個表 建議一般帶char字段的表不應超過500萬rows.基于數(shù)字的字段為主的表不要超過1000萬rows. 4.表的優(yōu)化n正確使用索

5、引，避免全表搜索n使用定長表,且定期做optimize table命令（注意這個命令會鎖表，請在數(shù)據庫訪問小的時候做）n在對大表進行添加索引，一定要選擇訪問小的時間段做，否則會導致嚴重問題。注:一般臨晨2-3點時候是大部分項目訪問的低谷。5.索引優(yōu)化、選擇和試驗n穩(wěn)妥地改進將需要優(yōu)化的相關表復制到測試環(huán)境在測試環(huán)境啟動一個測試daemon，關閉query cache或是使用select sql_no_cache 方式。未優(yōu)化時測試若干次查詢時間，以及explain檢查掃描集。選擇合適的索引試驗建立?？梢酝ㄟ^use index(xx)來強制使用。檢查是否有效。測試查詢時間變化，反復試驗得到最優(yōu)結果n保持關注，根據情況隨時改變索引設置6.關于排序的問題n盡量使用帶主鍵的字段做order by 的排序n盡量不要多提供頁面的查找（最好只提供100頁內），避免機器爬蟲抓取數(shù)據，導致數(shù)據庫壓力負載過高。因