荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: platinum.bbs@bbs.cqupt.edu.cn (BLUECRYSTAL), 信区: Linux
标 题: MySQL维护笔记
发信站: 幽幽黄桷兰 (Thu Jan 9 12:49:37 2003)
转信站: SZU!news.tiaozhan.com!news.happynet.org!CQUPT
MYSQL服务维护笔记
MYSQL服务维护笔记
http://www.chedong.com/tech/mysql.html
作者： 车东 chedong@bigfoot.com
最后更新：2002-12-31 13:50:26
版权声明：可以任意转载，转载时请务必标明原始出处和作者信息
内容摘要：使用MYSQL服务的一些经验，主要从以下几个方面考虑的MYSQL服务规划设计
。
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-cha
rset只在按字母排序的时候才有用，这些选项会对数据的迁移带来很多麻烦。
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 --da
tadir="$rundir"/var "$@"\
-O max_connections=500 -O wait_timeout=600 -O key_buffer=32M --port=3402 --s
ocket="$rundir"/mysql.sock &
注释：
--pid-file="$rundir"/mysql.pid --socket="$rundir"/mysql.sock --datadir="$run
dir"/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上运行了。
服务的备份
==========
尽量使用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文件中，系统就算是很好的恢复了。
灾难恢复：数据本身被破坏的情况下
确定破坏的时间点，然后从备份数据中恢复。
应用的设计要点
==============
非用数据库不可吗？虽然数据库的确可以简化很多应用的结构设计，但本身也是一个系
统资源消耗比较大的应用。所以在某些情况下文本，DBM比数据库是更好的选择，比如：
很多应用如果没有很高的实时统计需求的话，完全可以先记录到文件日志中，定期的导
入到数据库中做后续统计分析。如果还是需要记录2维表结构，结构足够简单的话可以使
用DBM结构。即使需要使用数据库的，应用如果没有太复杂的数据完整性需求的化，完全
可以不使用那些支持外键的商业数据库，比如MYSQL。只有非常需要完整的商业逻辑的时
候才需要ORACLE这样的大型数据库。完全可以把文件，DBM，MYSQL等轻量级做前端数据
存取，用ORACLE做数据库仓库完成复杂的数据库挖掘分析工作。
数据库服务的主要瓶颈：单个服务的连接数
对于一个应用来说，如果数据库表结构的设计能够按照数据库原理的范式来设计的话，
并且已经使用了最新版本的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]用于
跟踪分析应用瓶颈。
全文检索：如果相应字段没有做全文索引的化，全文检索将是一个非常消耗CPU的功能，
因为全文检索是用不上一般的索引的，关于全文索引可以参考一下基于JAVA的全文索引
引擎lucene的介绍。
参考文档：
MYSQL的参考：
http://www.mysql.com/documentation/mysql/bychapter/
--
※ 来源:·幽幽黄桷兰 bbs.cqupt.edu.cn·[FROM: blue.crystal]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店