熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> MySQL >> 正文

MYSQL服務維護筆記

2013-11-23 21:00:39  來源: MySQL 

  使用MYSQL服務的一些經驗主要從以下幾個方面考慮的MYSQL服務規劃設計
   MYSQL服務的安裝/配置的通用性
   系統的升級和數據遷移方便性
   備份和系統快速恢復
  
  MYSQL服務器的規劃
  =================
  為了以後維護升級備份的方便和數據的安全性最好將MYSQL程序文件和數據分別安裝在不同的硬件
  /
  /usr       <== 操作系統     }==> 硬盤
  /home/mysql   <== mysql應用程序
  
  /data/app_/   <== 應用數據和腳本  }==> 硬盤
  /data/app_/
  /data/app_/
  
  mysql服務的安裝和服務的啟動
  MYSQL一般使用當前STABLE的版本盡量不使用withcharset=選項我感覺withcharset只在按字母排序的時候才有用這些選項會對數據的遷移帶來很多麻煩
  configure prefix=/home/mysql
  make
  make install
  
  服務的啟動和停止
  ================
   復制缺省的mysql/var/mysql到 /data/app_/目錄下
   MYSQLD的啟動腳本start_mysqlsh
  #!/bin/sh
  rundir=`dirname $`
  echo $rundir
  /home/mysql/bin/safe_mysqld user=mysql pidfile=$rundir/mysqlpid datadir=$rundir/var $@O max_connections= O wait_timeout= O key_buffer=M port= socket=$rundir/mysqlsock &
  
  注釋
  pidfile=$rundir/mysqlpid socket=$rundir/mysqlsock datadir=$rundir/var
  目的都是將相應數據和應用臨時文件放在一起
  O 後面一般是服務器啟動全局變量優化參數有時候需要根據具體應用調整
  port: 不同的應用使用PORT參數分布到不同的服務上去一個服務可以提供的連接數一般是MYSQL服務的主要瓶頸
  
  修改不同的服務到不同的端口後在rclocal文件中加入
  /data/app_/start_mysqlsh
  /data/app_/start_mysqlsh
  /data/app_/start_mysqlsh
  注意必須寫全路徑
  
   MYSQLD的停止腳本stop_mysqlsh
  #!/bin/sh
  rundir=`dirname $`
  echo $rundir
  /home/mysql/bin/mysqladmin u mysql S$rundir/mysqlsock shutdown
  
  使用這個腳本的好處在於
   多個服務啟動只需要修改腳本中的port=參數單個目錄下的數據和服務腳本都是可以獨立打包的
   所有服務相應文件都位於/data/app_/目錄下比如mysqlpid mysqlsock當一台服務器上啟動多個服務時多個服務不會互相影響但都放到缺省的/tmp/下則有可能被其他應用誤刪
   當硬盤出問題以後直接將硬盤放到一台裝好MYSQL的服務器上就可以立刻恢復服務(如果放到f裡則還需要備份相應的配置文件)
  
  服務啟動後/data/app_/下相應的文件和目錄分布如下
  /data/app_/
        start_mysqlsh 服務啟動腳本
        stop_mysqlsh 服務停止腳本
        mysqlpid   服務的進程ID
        mysqlsock   服務的SOCK
        var/      數據區
          mysql/   用戶庫
          app__db_/ 應用庫
          app__db_/
         
  /data/app_/
         
  
  查看所有的應用進程ID
  cat /data/*/mysqlpid
  
  查看所有數據庫的錯誤日志
  cat /data/*/var/*err
  
  個人建議MYSQL的主要瓶頸在PORT的連接數上因此將表結構優化好以後相應單個MYSQL服務的CPU占用仍然在%以上就要考慮將服務拆分到多個PORT上運行了
  
  服務的備份
  ==========
  盡量使用MYSQL DUMP而不是直接備份數據文件以下是一個按weekday將數據輪循備份的腳本備份的間隔和周期可以根據備份的需求確定
  /home/mysql/bin/mysqldump S/data/app_/mysqlsock umysql db_name | gzip f>/path/to/backup/db_name`data +%w`dumpgz
  因此寫在CRONTAB中一般是
  * * * * /home/mysql/bin/mysqldump S/data/app_/mysqlsock umysql db_name | gzip f>/path/to/backup/db_name`data +\%w`dumpgz
  注意
   在crontab中%需要轉義成\%
   根據日志統計應用負載最低的時候一般是在早上
  
  先備份在本地然後傳到遠程的備份服務器上或者直接建立一個數據庫備份帳號直接在遠程的服務器上備份遠程備份只需要將以上腳本中的S /path/to/msyqlsock改成h IPADDRESS即可
  
  數據的恢復和系統的升級
  ======================
  日常維護和數據遷移在數據盤沒有被破壞的情況下
  硬盤一般是系統中壽命最低的硬件而系統(包括操作系統和MYSQL應用)的升級和硬件升級都會遇到數據遷移的問題
  只要數據不變先裝好服務器然後直接將數據盤(硬盤)安裝上只需要將啟動腳本重新加入到rclocal文件中系統就算是很好的恢復了
  
  災難恢復數據本身被破壞的情況下
  確定破壞的時間點然後從備份數據中恢復
  
  應用的設計要點
  ==============
  
   非用數據庫不可嗎?
  數據庫的確可以簡化很多應用的結構設計但本身也是一個系統資源消耗比較大的應用所以很多應用如果沒有很高的實時統計需求的話完全可以先記錄到文件日志中定期的導入到數據庫中做後續統計分析如果還是需要記錄維表結構結構足夠簡單的話可以使用DBM結構即使需要使用數據庫的應用如果沒有太復雜的數據完整性需求的化完全可以不使用那些支持外鍵的商業數據庫
  
   數據庫服務的主要瓶頸單個服務的連接數
  對於一個應用來說如果數據庫表結構的設計能夠按照數據庫原理的范式來設計的話並且已經使用了最新版本的MYSQL並且按照比較優化的方式運行了那麼最後的主要瓶頸一般在於單個服務的連接數即使一個數據庫可以支持並發個連接最好也不要把應用用到這個地步因為並發連接數過多數據庫服務本身用於調度的線程的開銷也會非常大了所以如果應用允許的話讓一台機器多跑幾個MYSQL服務分擔將服務均衡的規劃到多個MYSQL服務端口上比如app_ ==> app_ ==> app_ ==> 一個G內存的機器跑上個MYSQL是很正常的個MYSQLD承擔個並發連接效率要比讓個MYSQLD承擔個效率高的多當然這樣也會帶來一些應用編程上的復雜度
  
   使用單獨的數據庫服務器(不要和前台WEB服務搶內存)MYSQL擁有更多的內存就可能能有效的進行結果集的緩存
  
   應用盡量使用PCONNECT和polling機制用於節省MYSQL服務建立連接的開銷
  
   表的橫向拆分讓最常被訪問的%的數據放在一個小表裡%的歷史數據放在一個歸檔表裡數據中間通過定期搬家和定期刪除無效數據來節省這樣對於應用來說總是在%數據中進行選擇比較有利於數據的緩存不要指望MYSQL中對單表記錄數在萬級以上還有比較高的效率
  
   表的縱向拆分(過渡范化)將所有的定長字段(char int等)放在一個表裡所有的變長字段(varchartextblob等)放在另外一個表裡個表之間通過主鍵關聯這樣定長字段表可以得到很大的優化(甚至可以使用HEAP表類型數據完全在內存中存取)這裡也說明另外一個原則對於我們來說盡量使用定長字段可以通過空間的損失換取訪問效率的提高MYSQL之所以支持多種表類型實際上是針對不同應用提供了不同的優化方式
  
   仔細的檢查應用的索引設計甚至在服務啟動中加入 logslowqueries[=file]用於跟蹤分析應用瓶頸
From:http://tw.wingwit.com/Article/program/MySQL/201311/29443.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.