MySQL服务维护笔记

内容摘要：使用MySQL服务的一些经验，主要从如下几个方面考虑的MySQL服务规划设计。对于高负载站点来讲PHP和MySQL运行在一块儿（或者说任何应用和数据库运行在一块儿的规划）都是性能最大的瓶颈，这样的设计有如让人一手画圆一手画方，这样2我的的工做效率确定不如让一我的专门画圆一我的专门画方效率高，让应用和数据库都跑在一台高性能服务器上说不定还不如跑在2台普通服务器上快。

如下就是针对MySQL做为专门的数据库服务器的优化建议：

   1. MySQL服务的安装/配置的通用性；
   2. 系统的升级和数据迁移方便性；
   3. 备份和系统快速恢复；
   4. 数据库应用的设计要点；
   5. 一次应用优化实战；

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.`date +%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.`date +\%w`.dump.gz
注意：
1 在crontab中'%'须要转义成'\%'
2 根据日志统计，应用负载最低的时候通常是在早上4-6点

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

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

灾难恢复：数据库数据自己被破坏的状况下 肯定破坏的时间点，而后从备份数据中恢复。