程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> 關於MYSQL數據庫 >> MySQL服務維護筆記 續

MySQL服務維護筆記 續

編輯:關於MYSQL數據庫
盡量使用MySQL DUMP而不是直接備份數據文件,以下是一個按weekday將數據輪循備份的腳本:備份的間隔和周期可以根據備份的需求確定
/home/mysql/bin/mysqldump -S/data/app_1/mysql.sock -uMySQL db_name | gzip -f>/path/to/backup/db_name.`data +%w`.dump.gz

  因此寫在CRONTAB中一般是:
15 4 * * * /home/mysql/bin/mysqldump -S/data/app_1/mysql.sock -uMySQL db_name | gzip -f>/path/to/backup/db_name.`data +\%w`.dump.gz

  注意:

  1. 在crontab中'%'需要轉義成'\%'
  2. 根據日志統計,應用負載最低的時候一般是在早上4-6點

  先備份在本地然後傳到遠程的備份服務器上,或者直接建立一個數據庫備份帳號,直接在遠程的服務器上備份,遠程備份只需要將以上腳本中的-S /path/to/msyql.sock改成-h IP.ADDRESS即可。

  數據的恢復和系統的升級

  日常維護和數據遷移:在數據盤沒有被破壞的情況下硬盤一般是系統中壽命最低的硬件。而系統(包括操作系統和MySQL應用)的升級和硬件升級,都會遇到數據遷移的問題。

  只要數據不變,先裝好服務器,然後直接將數據盤(硬盤2)安裝上,只需要將啟動腳本重新加入到rc.local文件中,系統就算是很好的恢復了。

  災難恢復:數據庫數據本身被破壞的情況下確定破壞的時間點,然後從備份數據中恢復。

  應用的設計要點

  如果MySQL應用占用的CPU超過10%就應該考慮優化了。

  如果這個服務可以被其他非數據庫應用代替(比如很多基於數據庫的計數器完全可以用WEB日志統計代替)最好將其禁用:

  非用數據庫不可嗎?雖然數據庫的確可以簡化很多應用的結構設計,但本身也是一個系統資源消耗比較大的應用。在某些情況下文本,DBM比數據庫是更好的選擇,比如:很多應用如果沒有很高的實時統計需求的話,完全可以先記錄到文件日志中,定期的導入到數據庫中做後續統計分析。如果還是需要記錄簡單的2維鍵-值對應結構的話可以使用類似於DBM的HEAP類型表。因為HEAP表全部在內存中存取,效率非常高,但服務器突然斷電時有可能出現數據丟失,所以非常適合存儲在線用戶信息,日志等臨時數據。即使需要使用數據庫的,應用如果沒有太復雜的數據完整性需求的化,完全可以不使用那些支持外鍵的商業數據庫,比如MySQL。只有非常需要完整的商業邏輯和事務完整性的時候才需要Oracle這樣的大型數據庫。對於高負載應用來說完全可以把日志文件,DBM,MySQL等輕量級方式做前端數據采集格式,然後用Oracle MSSQL DB2 Sybase等做數據庫倉庫以完成復雜的數據庫挖掘分析工作。

  有朋友和我說用標准的MyISAM表代替了InnoDB表以後,數據庫性能提高了20倍。

  數據庫服務的主要瓶頸:單個服務的連接數對於一個應用來說,如果數據庫表結構的設計能夠按照數據庫原理的范式來設計的話,並且已經使用了最新版本的MySQL,並且按照比較優化的方式運行了,那麼最後的主要瓶頸一般在於單個服務的連接數,即使一個數據庫可以支持並發500個連接,最好也不要把應用用到這個地步,因為並發連接數過多數據庫服務本身用於調度的線程的開銷也會非常大了。所以如果應用允許的話:讓一台機器多跑幾個MySQL服務分擔。將服務均衡的規劃到多個MySQL服務端口上:比如app_1 ==> 3301 app_2 ==> 3302...app_9 ==> 3309。一個1G內存的機器跑上10個MySQL是很正常的。讓10個MySQLD承擔1000個並發連接效率要比讓2個MySQLD承擔1000個效率高的多。當然,這樣也會帶來一些應用編程上的復雜度;

  使用單獨的數據庫服務器(不要讓數據庫和前台WEB服務搶內存),MySQL擁有更多的內存就可能能有效的進行結果集的緩存;在前面的啟動腳本中有一個-O key_buffer=32M參數就是用於將缺省的8M索引緩存增加到32M(當然對於)

  應用盡量使用PCONNECT和polling機制,用於節省MySQL服務建立連接的開銷,但也會造成MySQL並發鏈接數過多(每個HTTPD都會對應一個MySQL線程);

  表的橫向拆分:讓最常被訪問的10%的數據放在一個小表裡,90%的歷史數據放在一個歸檔表裡(所謂:快慢表),數據中間通過定期“搬家”和定期刪除無效數據來節省,畢竟大部分應用(比如論壇)訪問2個月前數據的幾率會非常少,而且價值也不是很高。這樣對於應用來說總是在一個比較小的結果級中進行數據選擇,比較有利於數據的緩存,不要指望MySQL中對單表記錄條數在10萬級以上還有比較高的效率。而且有時候數據沒有必要做那麼精確,比如一個快表中查到了某個人發表的文章有60條結果,快表和慢表的比例是1:20,那麼就可以簡單的估計這個人一共發表了1200篇。Google的搜索結果數也是一樣:對於很多上十萬的結果數,後面很多的數字都是通過一定的算法估計出來的。

  數據庫字段設計:表的縱向拆分(過渡范化):將所有的定長字段(char, int等)放在一個表裡,所有的變長字段(varchar,text,blob等)放

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved