一、做了mysql主从也有一段时间了，这两天检查磁盘空间情况，发现放数据库的分区磁盘激增了40多G，一路查看下来，发现配置好主从复制以来到现在的binlog就有40多G，原来根源出在这里，查看了一下my.cnf，看到binlog的 size是1G就做分割，但没有看到删除的配置，在mysql里show了一下variables：
| mysql>show variables like '%log%'; |
查到了，
| | expire_logs_days | 0 | |
这个默认是0，也就是logs不过期，这个是一个global的参数，所以需要执行
| set global expire_logs_days=8; |
这样8天前的log就会被删除了，如果有回复的需要，请做好备份工作，但这样设置还不行，下次重启mysql了，配置又恢复默认了，所以需在my.cnf中设置，
| expire_logs_days = 8 |
这样重启也不怕了。
现在我在生产环境下的做法是将此时间设为0，然后备份mysql日志文件，然后再手动清理此文件。
想要恢复数据库以前的资料，执行
| mysql>show binlog events; |
由于数据量很多，查看起来很麻烦，光打开个文件就要闪半天，所以应该适当删除部分可不用的日志。
并且如果使用的时间足够长的话，会把我的硬盘空间都给吃掉。
1、登录系统，/usr/bin/mysql
使用mysql查看日志：
|
mysql>show binary logs; +—————-+———–+ | Log_name | File_size | +—————-+———–+ | ablelee.000001 | 150462942 | | ablelee.000002 | 120332942 | | ablelee.000003 | 141462942 | +—————-+———–+ |
2、删除bin-log（删除ablelee.000003之前的而没有包含ablelee.000003）：
|
mysql> purge binary logs to ′ablelee.000003′; Query OK, 0 rows affected (0.16 sec) |
3、查询结果（现在只有一条记录了）：
|
mysql> show binlog events\G *************************** 1. row *************************** Log_name: ablelee.000003 Pos: 4 Event_type: Format_desc Server_id: 1 End_log_pos: 106 Info: Server ver: 5.1.26-rc-log, Binlog ver: 4 1 row in set (0.01 sec) (ablelee.000001和ablelee.000002已被删除) mysql> show binary logs; +—————-+———–+ | Log_name | File_size | +—————-+———–+ | ablelee.000003 | 106 | +—————-+———–+ 1 row in set (0.00 sec) (删除的其它格式运用!) PURGE {MASTER | BINARY} LOGS TO ‘log_name’ PURGE {MASTER | BINARY} LOGS BEFORE ‘date’ |
用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除，这样被给定的日志成为第一个。
例如：
|
PURGE MASTER LOGS TO 'mysql-bin.010'; PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00'; |
二、现在手上蛮多项目的数据库用的是MySQL，由于权限等原因，暂时不方便部署Nagios监控MySQL主从复制，所以我一般在从机上配置了SHELL脚本用来监控MySQL的主从状态（设置为每十分钟运行一次），并且每次出问题时将确切日期写进错误日志，方便事后排查原因，脚本内容如下：
|
#!/bin/bash #check MySQL_Slave Status #crontab time 00:10 MYSQLPORT=`netstat -na|grep "LISTEN"|grep "3306"|awk -F[:" "]+ '{print $4}'` MYSQLIP=`ifconfig eth0|grep "inet addr" | awk -F[:" "]+ '{print $4}'` STATUS=$(/usr/local/webserver/mysql/bin/mysql -u yuhongchun -pyuhongchun101 -S /tmp/mysql.sock -e "show slave status\G" | grep -i "running") IO_env=`echo $STATUS | grep IO | awk ' {print $2}'` SQL_env=`echo $STATUS | grep SQL | awk '{print $2}'` if [ "$MYSQLPORT" == "3306" ] if [ "$IO_env" = "Yes" -a "$SQL_env" = "Yes" ] |
建议每十分钟运行一次。
| */10 * * * * root /bin/sh /root/mysql_slave.sh |
记得在每台MySQL从机上分配一个yuhongchun的用户，权限大些也没关系，只限定在本地运行，如下所示：
|
grant all privileges on *.* to "yuhongchun"@"127.0.0.1" identified by "yuhongchun101"; grant all privileges on *.* to "yuhongchun"@"localhost" identified by "yuhongchun101"; |
脚本设计思路：
1、此脚本应该能适应各种各样不同的内外网环境，即IP不同的环境；
2、让脚本也顺便监控下MySQL是否正常运行；
三、innodb_buffer_pool_size的设置。
这个参数定义了InnodDB存储引擎的表数据和索引数据的最大内存缓冲区大小。和MyISAM存储引擎不同，MyISAM的key_buffer_size只缓存索引键，而innodb_buffer_pool_size却是同时为数据块和索引块 做缓存，这个特征和Oracle是一样的，这个值设得越高，访问表中数据需求的I/O就越少。在一个专用的数据库服务器，可以设置这个参数达机器物理内存的80%，我现在一般的做法是配置成物理内存的 1/4，比如8G内存的生产数据库，我一般会配置成2G左右。
四、测试了很长一段时间的MySQL的负载均衡，最后综合了老男孩和其它技术高手的意见，最终决定还是用LVS+Keepalived来作为MySQL的负载均衡，这是因为后端机器超过10台时，LVS的性能还是最好的；如果在3-5台左右，HAProxy也可以很轻松的搞定工作。
五、大家都很清，磁盘I/O总会成为数据库的性能瓶颈，这时候我们应该如何在生产环境下选择合适的RAID级别呢？
1、如果数据读写都很频繁，可靠性要求也很高，最好选择RAID10；
2、如果数据读很频繁，写相对较少，对可靠性有一定要求，可以选择RAID5；
3、如果数据读写都很频繁，但可靠性要求不高，可以选择RAID0。
4、对于核心业务的数据库主从同步，建议从机的备份时间往后延迟一段时间，通常的做法是延迟一天左右。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/