知识大全 MYSQL服务维护笔记

Posted 2022-07-15 知

篇首语：汗水和丰收是忠实的伙伴，勤学和知识是一对最美丽的情侣。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 MYSQL服务维护笔记相关的知识，希望对你有一定的参考价值。

MYSQL服务维护笔记 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　使用MYSQL服务的一些经验主要从以下几个方面考虑的MYSQL服务规划设计　　 MYSQL服务的安装/配置的通用性　　系统的升级和数据迁移方便性　　备份和系统快速恢复　　　　 MYSQL服务器的规划　　=================　　为了以后维护升级备份的方便和数据的安全性最好将MYSQL程序文件和数据分别安装在不同的硬件上　　/ 　　/usr　　　　　　 <== 操作系统　　　　 ==> 硬盘　　/home/mysql　　　<== mysql应用程序　　　　/data/app_ /　　 <== 应用数据和脚本　 ==> 硬盘　　/data/app_ /　　/data/app_ /　　　　mysql服务的安装和服务的启动　　MYSQL一般使用当前STABLE的版本尽量不使用 with charset=选项我感觉with charset只在按字母排序的时候才有用这些选项会对数据的迁移带来很多麻烦　　configure prefix=/home/mysql　　make 　　make install　　　　 服务的启动和停止　　================　　复制缺省的mysql/var/mysql到 /data/app_ /目录下　　 MYSQLD的启动脚本 start_mysql sh　　#!/bin/sh　　rundir=`dirname $ `　　echo $rundir 　　/home/mysql/bin/safe_mysqld user=mysql pid file= $rundir /mysql pid datadir= $rundir /var $@ O max_connections= O wait_timeout= O key_buffer= M port= socket= $rundir /mysql sock & 　　　　注释　　 pid file= $rundir /mysql pid　 socket= $rundir /mysql sock datadir= $rundir /var 　　目的都是将相应数据和应用临时文件放在一起　　 O 后面一般是服务器启动全局变量优化参数有时候需要根据具体应用调整　　 port: 不同的应用使用PORT参数分布到不同的服务上去一个服务可以提供的连接数一般是MYSQL服务的主要瓶颈　　　　修改不同的服务到不同的端口后在rc local文件中加入　　/data/app_ /start_mysql sh　　/data/app_ /start_mysql sh　　/data/app_ /start_mysql sh　　注意必须写全路径　　　　 MYSQLD的停止脚本 stop_mysql sh　　#!/bin/sh　　rundir=`dirname $ `　　echo $rundir 　　/home/mysql/bin/mysqladmin u mysql S $rundir /mysql sock shutdown 　　　　使用这个脚本的好处在于　　多个服务启动只需要修改脚本中的 port=参数单个目录下的数据和服务脚本都是可以独立打包的　　所有服务相应文件都位于/data/app_ /目录下比如 mysql pid mysql sock 当一台服务器上启动多个服务时多个服务不会互相影响但都放到缺省的/tmp/下则有可能被其他应用误删　　当硬盘出问题以后直接将硬盘放到一台装好MYSQL的服务器上就可以立刻恢复服务（如果放到f里则还需要备份相应的配置文件）　　　　服务启动后/data/app_ /下相应的文件和目录分布如下　　/data/app_ /　　　　　　　　start_mysql sh 服务启动脚本　　　　　　　　stop_mysql sh　服务停止脚本　　　　　　　　mysql pid　　　服务的进程ID　　　　　　　　mysql sock　　服务的SOCK　　　　　　　　var/　　　　　数据区　　　　　　　　　 mysql/　　　用户库　　　　　　　　　 app_ _db_ / 应用库　　　　　　　　　 app_ _db_ /　　　　　　　　　　　/data/app_ /　　　　　　　　　　　　查看所有的应用进程ID 　　cat /data/*/mysql pid 　　　　查看所有数据库的错误日志　　cat /data/*/var/* err 　　　　个人建议 MYSQL的主要瓶颈在PORT的连接数上因此将表结构优化好以后相应单个MYSQL服务的CPU占用仍然在％以上就要考虑将服务拆分到多个PORT上运行了　　　　 服务的备份　　==========　　尽量使用MYSQL DUMP而不是直接备份数据文件以下是一个按weekday将数据轮循备份的脚本备份的间隔和周期可以根据备份的需求确定　　/home/mysql/bin/mysqldump S/data/app_ /mysql sock umysql db_name | gzip f>/path/to/backup/db_name `data +%w` dump gz　　因此写在CRONTAB中一般是　　* * * * /home/mysql/bin/mysqldump S/data/app_ /mysql sock umysql db_name | gzip f>/path/to/backup/db_name `data +\\%w` dump gz　　注意　　在crontab中 % 需要转义成 \\% 　　根据日志统计应用负载最低的时候一般是在早上点　　　　先备份在本地然后传到远程的备份服务器上或者直接建立一个数据库备份帐号直接在远程的服务器上备份远程备份只需要将以上脚本中的 S /path/to/msyql sock改成 h IP ADDRESS即可　　　　 数据的恢复和系统的升级　　======================　　日常维护和数据迁移在数据盘没有被破坏的情况下　　硬盘一般是系统中寿命最低的硬件而系统（包括操作系统和MYSQL应用）的升级和硬件升级都会遇到数据迁移的问题　　只要数据不变先装好服务器然后直接将数据盘（硬盘）安装上只需要将启动脚本重新加入到rc local文件中系统就算是很好的恢复了　　　　灾难恢复数据本身被破坏的情况下　　确定破坏的时间点然后从备份数据中恢复　　　　 应用的设计要点　　==============　　　　非用数据库不可吗？　　数据库的确可以简化很多应用的结构设计但本身也是一个系统资源消耗比较大的应用所以很多应用如果没有很高的实时统计需求的话完全可以先记录到文件日志中定期的导入到数据库中做后续统计分析如果还是需要记录维表结构结构足够简单的话可以使用DBM结构即使需要使用数据库的应用如果没有太复杂的数据完整性需求的化完全可以不使用那些支持外键的商业数据库　　　　数据库服务的主要瓶颈单个服务的连接数　　对于一个应用来说如果数据库表结构的设计能够按照数据库原理的范式来设计的话并且已经使用了最新版本的MYSQL 并且按照比较优化的方式运行了那么最后的主要瓶颈一般在于单个服务的连接数即使一个数据库可以支持并发个连接最好也不要把应用用到这个地步因为并发连接数过多数据库服务本身用于调度的线程的开销也会非常大了所以如果应用允许的话让一台机器多跑几个MYSQL服务分担将服务均衡的规划到多个MYSQL服务端口上比如app_ ==> app_ ==> app_ ==> 一个 G内存的机器跑上个MYSQL是很正常的让个MYSQLD承担个并发连接效率要比让个MYSQLD承担个效率高的多当然这样也会带来一些应用编程上的复杂度　　　　使用单独的数据库服务器（不要和前台WEB服务抢内存） MYSQL拥有更多的内存就可能能有效的进行结果集的缓存　　　　应用尽量使用PCONNECT和polling机制用于节省MYSQL服务建立连接的开销　　　　表的横向拆分让最常被访问的 %的数据放在一个小表里 %的历史数据放在一个归档表里数据中间通过定期搬家和定期删除无效数据来节省这样对于应用来说总是在 %数据中进行选择比较有利于数据的缓存不要指望MYSQL中对单表记录数在万级以上还有比较高的效率　　　　表的纵向拆分（过渡范化）将所有的定长字段（char int等）放在一个表里所有的变长字段（varchar text blob等）放在另外一个表里个表之间通过主键关联这样定长字段表可以得到很大的优化（甚至可以使用HEAP表类型数据完全在内存中存取）这里也说明另外一个原则对于我们来说尽量使用定长字段可以通过空间的损失换取访问效率的提高 MYSQL之所以支持多种表类型实际上是针对不同应用提供了不同的优化方式　　　　仔细的检查应用的索引设计甚至在服务启动中加入 log slow queries[=file]用于跟踪分析应用瓶颈 cha138/Article/program/MySQL/201311/29443