mysql的维护设计_mysql的维护设计_MYSQL服务维护及应用设计笔记

1 多个服务启动：只须要修改脚本中的--port=参数。单个目录下的数据和服务脚本都是能够独立打包的。mysql

2 全部服务相应文件都位于/data/app_1/目录下：好比：mysql.pid mysql.sock，当一台服务器上启动多个服务时，多个服务不会互相影响。但都放到缺省的/tmp/下则有可能被其余应用误删。sql

3 当硬盘1出问题之后，直接将硬盘2放到一台装好MYSQL的服务器上就能够马上恢复服务(若是放到my.cnf里则还须要备份相应的配置文件)。数据库

服务启动后/data/app_1/下相应的文件和目录分布以下：编程

/data/app_1/缓存

start_mysql.sh 服务启动脚本服务器

stop_mysql.sh 服务中止脚本并发

mysql.pid 服务的进程IDapp

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文件中，系统就算是很好的恢复了。

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

应用的设计要点

1.非用数据库不可吗？

数据库的确能够简化不少应用的结构设计，但自己也是一个系统资源消耗比较大的应用。因此不少应用若是没有很高的实时统计需求的话，彻底能够先记录到文件日志中，按期的导入到数据库中作后续统计分析。若是仍是须要记录2维表结构，结构足够简单的话可使用DBM结构。即便须要使用数据库的，应用若是没有太复杂的数据完整性需求的化，彻底能够不使用那些支持外键的商业数据库。

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拥有更多的内存就可能能有效的进行结果集的缓存；

4.应用尽可能使用PCONNECT和polling机制，用于节省MYSQL服务创建链接的开销；

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

6.表的纵向拆分(过渡范化)：将全部的定长字段(char, int等)放在一个表里，全部的变长字段(varchar,text,blob等)放在另一个表里，2个表之间经过主键关联，这样，定长字段表能够获得很大的优化(甚至可使用HEAP表类型，数据彻底在内存中存取)，这里也说明另一个原则，对于咱们来讲，尽可能使用定长字段能够经过空间的损失换取访问效率的提升。MYSQL之因此支持多种表类型，其实是针对不一样应用提供了不一样的优化方式；

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