茫茫網海中的冷日
         
茫茫網海中的冷日
發生過的事，不可能遺忘，只是想不起來而已！
 恭喜您是本站第 1671634 位訪客!  登入  | 註冊
主選單

Google 自訂搜尋

Goole 廣告

隨機相片
IMG_00072.jpg

授權條款

使用者登入
使用者名稱:

密碼:


忘了密碼?

現在就註冊!

DB研討會 : [轉貼]MYSQL服務維護筆記_Part-1

討論區主頁 - 主題一覽 > DB研討會 > [轉貼]MYSQL服務維護筆記_Part-1
討論串 | 最新的先
前一個主題 | 下一個主題 | 頁尾
主題一覽的上方
發表者 討論內容
冷日
(冷日)		 發表時間：2008/3/19 5:41
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]MYSQL服務維護筆記_Part-1
MYSQL服务维护笔记

作者： 车东
Monday, July 29 2002 5:08 PM 本文介绍作者使用MYSQL服务的一些经验，主要从以下几个方面讲解MYSQL服务规划设计：
1 MYSQL服务的安装/配置的通用性；
2 系统的升级和数据迁移方便性；
3 备份和系统快速恢复；

MYSQL服务器的规划

为了以后维护，升级备份的方便和数据的安全性，最好将MYSQL程序文件和数据分别安装在“不同的硬件”上。
/
/usr <== 操作系统 }==> 硬盘1
/home/mysql <== mysql应用程序
...
/data/app_1/ <== 应用数据和脚本 }==> 硬盘2
/data/app_2/
/data/app_3/

mysql服务的安装和服务的启动：
MYSQL一般使用当前STABLE的版本，尽量不使用--with-charset=选项，我感觉with-charset只在按字母排序的时候才有用，这些选项会对数据的迁移带来很多麻烦。
configure --prefix=/home/mysql
make 
make install

服务的启动和停止
1 复制缺省的mysql/var/mysql到 /data/app_1/目录下，
2 MYSQLD的启动脚本：start_mysql.sh
#!/bin/sh
rundir=`dirname "$0"`
echo "$rundir"
/home/mysql/bin/safe_mysqld --user=mysql --pid-file="$rundir"/mysql.pid --datadir="$rundir"/var "$@"\
-O max_connections=500 -O wait_timeout=600 -O key_buffer=32M --port=3402 --socket="$rundir"/mysql.sock &

注释：
--pid-file="$rundir"/mysql.pid --socket="$rundir"/mysql.sock --datadir="$rundir"/var
目的都是将相应数据和应用临时文件放在一起；
-O 后面一般是服务器启动全局变量优化参数，有时候需要根据具体应用调整；
--port: 不同的应用使用PORT参数分布到不同的服务上去，一个服务可以提供的连接数一般是MYSQL服务的主要瓶颈；

修改不同的服务到不同的端口后，在rc.local文件中加入：
/data/app_1/start_mysql.sh
/data/app_2/start_mysql.sh
/data/app_3/start_mysql.sh
注意：必须写全路径


3 MYSQLD的停止脚本：stop_mysql.sh
#!/bin/sh
rundir=`dirname "$0"`
echo "$rundir"
/home/mysql/bin/mysqladmin -u mysql -S"$rundir"/mysql.sock shutdown

使用这个脚本的好处在于：
1 多个服务启动：只需要修改脚本中的--port=参数。单个目录下的数据和服务脚本都是可以独立打包的。
2 所有服务相应文件都位于/data/app_1/目录下：比如：mysql.pid mysql.sock，当一台服务器上启动多个服务时，多个服务不会互相影响。但都放到缺省的/tmp/下则有可能被其他应用误删。
3 当硬盘1出问题以后，直接将硬盘2放到一台装好MYSQL的服务器上就可以立刻恢复服务（如果放到my.cnf里则还需要备份相应的配置文件）。

服务启动后/data/app_1/下相应的文件和目录分布如下：
/data/app_1/
start_mysql.sh 服务启动脚本
stop_mysql.sh 服务停止脚本
mysql.pid 服务的进程ID
mysql.sock 服务的SOCK
var/ 数据区
mysql/ 用户库
app_1_db_1/ 应用库
app_2_db_2/
...
/data/app_2/
...

查看所有的应用进程ID：
cat /data/*/mysql.pid


查看所有数据库的错误日志：
cat /data/*/var/*.err


个人建议：MYSQL的主要瓶颈在PORT的连接数上，因此，将表结构优化好以后，相应单个MYSQL服务的CPU占用仍然在10％以上，就要考虑将服务拆分到多个PORT上运行了。
回覆
冷日
(冷日)		 發表時間：2008/3/19 5:44
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]MYSQL服務維護筆記_Part-2
服务的备份
尽量使用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中一般是：
* 6 * * * /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 根据日志统计，应用负载最低的时候一般是在早上6点

先备份在本地然后传到远程的备份服务器上，或者直接建立一个数据库备份帐号，直接在远程的服务器上备份，远程备份只需要将以上脚本中的-S /path/to/msyql.sock改成-h IP.ADDRESS即可。

数据的恢复和系统的升级
日常维护和数据迁移：在数据盘没有被破坏的情况下
硬盘一般是系统中寿命最低的硬件。而系统（包括操作系统和MYSQL应用）的升级和硬件升级，都会遇到数据迁移的问题。
只要数据不变，先装好服务器，然后直接将数据盘（硬盘2）安装上，只需要将启动脚本重新加入到rc.local文件中，系统就算是很好的恢复了。

灾难恢复：数据本身被破坏的情况下
确定破坏的时间点，然后从备份数据中恢复。

应用的设计要点
非用数据库不可吗？
数据库的确可以简化很多应用的结构设计，但本身也是一个系统资源消耗比较大的应用。所以很多应用如果没有很高的实时统计需求的话，完全可以先记录到文件日志中，定期的导入到数据库中做后续统计分析。如果还是需要记录2维表结构，结构足够简单的话可以使用DBM结构。即使需要使用数据库的，应用如果没有太复杂的数据完整性需求的化，完全可以不使用那些支持外键的商业数据库，

数据库服务的主要瓶颈：单个服务的连接数
对于一个应用来说，如果数据库表结构的设计能够按照数据库原理的范式来设计的话，并且已经使用了最新版本的MYSQL，并且按照比较优化的方式运行了，那么最后的主要瓶颈一般在于单个服务的连接数，即使一个数据库可以支持并发500个连接，最好也不要把应用用到这个地步，因为并发连接数过多数据库服务本身用于调度的线程的开销也会非常大了。所以如果应用允许的话：让一台机器多跑几个MYSQL服务分担。将服务均衡的规划到多个MYSQL服务端口上：比如app_1 ==> 3301 app_2 ==> 3302...app_9 ==> 3309。一个1G内存的机器跑上10个MYSQL是很正常的。让10个MYSQLD承担1000个并发连接效率要比让2个MYSQLD承担1000个效率高的多。当然，这样也会带来一些应用编程上的复杂度；

使用单独的数据库服务器（不要和前台WEB服务抢内存），MYSQL拥有更多的内存就可能能有效的进行结果集的缓存；

应用尽量使用PCONNECT和polling机制，用于节省MYSQL服务建立连接的开销；

表的横向拆分：让最常被访问的10%的数据放在一个小表里，90%的历史数据放在一个归档表里，数据中间通过定期“搬家”和定期删除无效数据来节省。这样对于应用来说总是在10%数据中进行选择，比较有利于数据的缓存，不要指望MYSQL中对单表记录数在10万级以上还有比较高的效率。

表的纵向拆分（过渡范化）：将所有的定长字段（char, int等）放在一个表里，所有的变长字段（varchar,text,blob等）放在另外一个表里，2个表之间通过主键关联，这样，定长字段表可以得到很大的优化（甚至可以使用HEAP表类型，数据完全在内存中存取），这里也说明另外一个原则，对于我们来说，尽量使用定长字段可以通过空间的损失换取访问效率的提高。MYSQL之所以支持多种表类型，实际上是针对不同应用提供了不同的优化方式；

仔细的检查应用的索引设计，甚至在服务启动中加入 --log-slow-queries[=file]用于跟踪分析应用瓶颈。
　
参考文档：

MYSQL的命令行选项请参考：
http://www.mysql.com/doc/C/o/Command-line_options.html
回覆
冷日
(冷日)		 發表時間：2008/3/19 5:44
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]MySQL服務維護筆記-繁體版
MySQL服務維護筆記(上)
作者：車東 發文時間：2004.06.08

以下就是針對MySQL作為專門的數據庫伺服器的優化建議：

MySQL伺服器的規劃

為了以後維護，升級備份的方便和數據的安全性，最好將MySQL程式文件和數據分別安裝在“不同的硬體”上。


/ /
| /usr <== 作業系統
| /home/mysql <== mysql主目錄，為了方便升級，這只
硬盤1==>| 是一個最新版本目錄的鏈結
| /home/mysql-3.23.54/ <== 最新版本的mysql /home/mysql鏈結到這裡
\ /home/mysql-old/ <== 以前運行的舊版本的mysql

/ /data/app_1/ <== 應用數據和啟動腳本等
硬盤2==>| /data/app_2/
\ /data/app_3/

MySQL服務的安裝和服務的啟動

MySQL一般使用當前STABLE的版本：

儘量不使用--with-charset=選項，我感覺with-charset只在按字母排序的時候才有用，這些選項會對數據的遷移帶來很多麻煩。

儘量不使用innodb，innodb主要用於需要外鍵，事務等企業級支援，代價是速度比MYISAM有數量級的下降。

./configure --prefix=/home/mysql --without-innodb
make
make install

服務的啟動和停止

1 複製缺省的mysql/var/mysql到 /data/app_1/目錄下。

2 MySQLD的啟動腳本：start_mysql.sh

#!/bin/sh
rundir=`dirname "$0"`
echo "$rundir"
/home/mysql/bin/safe_mysqld --user=mysql --pid-file=
"$rundir"/mysql.pid --datadir="$rundir"/var "$@"\-O
max_connections=500 -O wait_timeout=600 -O key_buffer=
32M --port=3402 --socket="$rundir"/mysql.sock &



註釋：

--pid-file="$rundir"/mysql.pid --socket="$rundir"/mysql.sock --datadir="$rundir"/var

目的都是將相應數據和應用臨時文件放在一起；
-O 後面一般是伺服器啟動全局變數優化參數，有時候需要根據具體應用調整；
--port: 不同的應用使用PORT參數分佈到不同的服務上去，一個服務可以提供的連接數一般是MySQL服務的主要瓶頸；

修改不同的服務到不同的端口後，在rc.local文件中加入：

/data/app_1/start_mysql.sh
/data/app_2/start_mysql.sh
/data/app_3/start_mysql.sh

注意：必須寫全路徑

3 MySQLD的停止腳本：stop_mysql.sh

#!/bin/sh
rundir=`dirname "$0"`
echo "$rundir"
/home/mysql/bin/mysqladmin -u mysql -S"$rundir"/mysql.sock shutdown



使用這個腳本的好處在於：

1 多個服務啟動：對於不同服務只需要修改腳本中的--port[=端口號]參數。單個目錄下的數據和服務腳本都是可以獨立打包的。
2 所有服務相應文件都位於/data/app_1/目錄下：比如：mysql.pid mysql.sock，當一台伺服器上啟動多個服務時，多個服務不會互相影響。但都放到缺省的/tmp/下則有可能被其他應用誤刪。
3 當硬盤1齣問題以後，直接將硬盤2放到一台裝好MySQL的伺服器上就可以立刻恢復服務（如果放到my.cnf裏則還需要備份相應的配置文件）。

服務啟動後/data/app_1/下相應的文件和目錄分佈如下：

/data/app_1/
start_mysql.sh 服務啟動腳本
stop_mysql.sh 服務停止腳本
mysql.pid 服務的進程ID
mysql.sock 服務的SOCK
var/ 數據區
mysql/ 用戶庫
app_1_db_1/ 應用庫
app_1_db_2/
...
/data/app_2/
...



查看所有的應用進程ID：
cat /data/*/mysql.pid

查看所有數據庫的錯誤日誌：
cat /data/*/var/*.err

個人建議：MySQL的主要瓶頸在PORT的連接數上，因此，將表結構優化好以後，相應單個MySQL服務的CPU佔用仍然在10％以上，就要考慮將服務拆分到多個PORT上運行了。

服務的備份

儘量使用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服務維護筆記(下)
作者：車東 發文時間：2004.06.10

應用的設計要點

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

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

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

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

3.使用單獨的數據庫伺服器（不要讓數據庫和前臺WEB服務搶記憶體），MySQL擁有更多的記憶體就可能能有效的進行結果集的緩存；在前面的啟動腳本中有一個-O key_buffer=32M參數就是用於將缺省的8M索引緩存增加到32M（當然對於）

4.應用儘量使用PCONNECT和polling機制，用於節省MySQL服務建立連接的開銷，但也會造成MySQL併發鏈結數過多（每個HTTPD都會對應一個MySQL線程）；

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

6.數據庫字段設計：表的縱向拆分（過渡範化）：將所有的定長字段（char, int等）放在一個表裏，所有的變長字段（varchar,text,blob等）放在另外一個表裏，2個表之間通過主鍵關聯，這樣，定長字段表可以得到很大的優化（這樣可以使用HEAP表類型，數據完全在記憶體中存取），這裡也說明另外一個原則，對於我們來說，儘量使用定長字段可以通過空間的損失換取訪問效率的提高。在MySQL4中也出現了支援外鍵和事務的InnoDB類型表，標準的MyISAM格式錶和基於HASH結構的HEAP記憶體表，MySQL之所以支援多種表類型，實際上是針對不同應用提供了不同的優化方式；

7.仔細的檢查應用的索引設計：可以在服務啟動參數中加入 --log-slow-queries[=file]用於跟蹤分析應用瓶頸，對於跟蹤服務瓶頸最簡單的方法就是用MySQL的status查看MySQL服務的運行統計和show processlist來查看當前服務中正在運行的SQL，如果某個SQL經常出現在PROCESS LIST中，一。有可能被查詢的此時非常多，二，裏面有影響查詢的字段沒有索引，三，返回的結果數過多數據庫正在排序（SORTING）；所以做一個腳本：比如每2秒運行以下show processlist;把結果輸出到文件中，看到底是什麼查詢在吃CPU。

8.全文檢索：如果相應字段沒有做全文索引的話，全文檢索將是一個非常消耗CPU的功能，因為全文檢索是用不上一般數據庫的索引的，所以要進行相應字段記錄遍歷。關於全文索引可以參考一下基於Java的全文索引引擎lucene的介紹。

9.前臺應用的記錄緩存：比如一個經常使用數據庫認證，如果需要有更新用戶最後登陸時間的操作，最好記錄更新後就把用戶放到一個緩存中（設置2個小時後過期），這樣如果用戶在2個小時內再次使用到登陸，就直接從緩存裏認證，避免了過於頻繁的數據庫操作。

10.查詢優先的表應該盡可能為where和order by字句中的字段加上索引，數據庫更新插入優先的應用索引越少越好。

總之：對於任何數據庫單表記錄超過100萬條優化都是比較困難的，關鍵是要把應用能夠轉化成數據庫比較擅長的數據上限內。也就是把複雜需求簡化成比較成熟的解決方案內。

一次優化實戰

以下例子是對一個論壇應用進行的優化：

1.用Webalizer代替了原來的通過數據庫的統計。

2.首先通過TOP命令查看MySQL服務的CPU佔用左右80%和記憶體佔用：10M，說明數據庫的索引緩存已經用完了，修改啟動參數，增加了-O key_buffer=32M，過一段時間等數據庫穩定後看的記憶體佔用是否達到上限。最後將緩存一直增加到64M，數據庫緩存才基本能充分使用。對於一個數據庫應用來說，把記憶體給數據庫比給WEB服務實用的多，因為MySQL查詢速度的提高能加快web應用從而節省併發的WEB服務所佔用的記憶體資源。

3.用show processlist;統計經常出現的SQL：

每分鐘運行一次show processlist並記錄日誌：

* * * * * (/home/mysql/bin/mysql -uuser -ppassword < /home/chedong/show_processlist.sql >> /home/chedong/mysql_processlist.log)

show_processlist.sql裏就一句：

show processlist;

比如可以從日誌中將包含where的字句過濾出來：
grep where mysql_processlist.log

如果發現有死鎖，一定要重新審視一下數據庫設計了，對於一般情況：查詢速度很慢，就將SQL where字句中沒有索引的字段加上索引，如果是排序慢就將order by字句中沒有索引的字段加上。對於有%like%的查詢，考慮以後禁用和使用全文索引加速。

4.還是根據show processlist;看經常有那些數據庫被頻繁使用，考慮將數據庫拆分到其他服務端口上。

MSSQL到MySQL的數據遷移：ACCESS＋MySQL ODBC Driver

在以前的幾次數據遷移實踐過程中，我發現最簡便的數據遷移過程並不是通過專業的數據庫遷移工具，也不是MSSQL自身的DTS進行數據遷移（遷移過程中間會有很多表出錯誤警告），但通過將MSSQL數據庫通過ACCESS獲取外部數據導入到數據庫中，然後用ACCESS的表==>右鍵==>導出，制定ODBC，通過MySQL的DSN將數據導出。這樣遷移大部分數據都會非常順利，如果導出的表有索引問題，還會出添加索引提示（DTS就不行），然後剩餘的工作就是在MySQL中設計字段對應的SQL腳本了。

全文完
回覆
主題一覽的下方
討論串
前一個主題 | 下一個主題 | 頁首 | | |

| Powered by XOOPS 2.0 © 2001-2008 The XOOPS Project|