MYSQL服务维护及应用设计笔记

使用这个脚本的好处在于：

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

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

应用的设计要点

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

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有