一、做了mysql主從也有一段時間了，這兩天檢查磁盤空間情況，發(fā)現(xiàn)放數(shù)據(jù)庫的分區(qū)磁盤激增了40多G，一路查看下來，發(fā)現(xiàn)配置好主從復(fù)制以來到現(xiàn)在的binlog就有40多G，原來根源出在這里，查看了一下my.cnf，看到binlog的 size是1G就做分割，但沒有看到刪除的配置，在mysql里show了一下variables：
| mysql>show variables like '%log%'; |
查到了，
這個默認(rèn)是0，也就是logs不過期，這個是一個global的參數(shù)，所以需要執(zhí)行
| set global expire_logs_days=8; |
這樣8天前的log就會被刪除了，如果有回復(fù)的需要，請做好備份工作，但這樣設(shè)置還不行，下次重啟mysql了，配置又恢復(fù)默認(rèn)了，所以需在my.cnf中設(shè)置，
這樣重啟也不怕了。
現(xiàn)在我在生產(chǎn)環(huán)境下的做法是將此時間設(shè)為0，然后備份mysql日志文件，然后再手動清理此文件。
想要恢復(fù)數(shù)據(jù)庫以前的資料，執(zhí)行
| mysql>show binlog events; |
由于數(shù)據(jù)量很多，查看起來很麻煩，光打開個文件就要閃半天，所以應(yīng)該適當(dāng)刪除部分可不用的日志。
并且如果使用的時間足夠長的話，會把我的硬盤空間都給吃掉。
1、登錄系統(tǒng)，/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、查詢結(jié)果（現(xiàn)在只有一條記錄了）：
| 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’ |
用于刪除列于在指定的日志或日期之前的日志索引中的所有二進(jìn)制日志。這些日志也會從記錄在日志索引文件中的清單中被刪除，這樣被給定的日志成為第一個。
例如：
| PURGE MASTER LOGS TO 'mysql-bin.010'; PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00'; |
二、現(xiàn)在手上蠻多項目的數(shù)據(jù)庫用的是MySQL，由于權(quán)限等原因，暫時不方便部署Nagios監(jiān)控MySQL主從復(fù)制，所以我一般在從機(jī)上配置了SHELL腳本用來監(jiān)控MySQL的主從狀態(tài)（設(shè)置為每十分鐘運行一次），并且每次出問題時將確切日期寫進(jìn)錯誤日志，方便事后排查原因，腳本內(nèi)容如下：
| #!/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" ] then echo "mysql is running" else mail -s "warn!server: $MYSQLIP mysql is down" yuhongchun027@163.com fi if [ "$IO_env" = "Yes" -a "$SQL_env" = "Yes" ] then echo "Slave is running!" else echo "####### $date #########">> /data/data/check_mysql_slave.log echo "Slave is not running!" >> /data/data/check_mysql_slave.log mail -s "warn! $MySQLIP_replicate_error" yuhongchun027@163.com << /data/data/check_mysql_slave.log fi |
建議每十分鐘運行一次。
| */10 * * * * root /bin/sh /root/mysql_slave.sh |
記得在每臺MySQL從機(jī)上分配一個yuhongchun的用戶，權(quán)限大些也沒關(guān)系，只限定在本地運行，如下所示：
| grant all privileges on *.* to "yuhongchun"@"127.0.0.1" identified by "yuhongchun101"; grant all privileges on *.* to "yuhongchun"@"localhost" identified by "yuhongchun101"; |
腳本設(shè)計思路：
1、此腳本應(yīng)該能適應(yīng)各種各樣不同的內(nèi)外網(wǎng)環(huán)境，即IP不同的環(huán)境；
2、讓腳本也順便監(jiān)控下MySQL是否正常運行；
三、innodb_buffer_pool_size的設(shè)置。
這個參數(shù)定義了InnodDB存儲引擎的表數(shù)據(jù)和索引數(shù)據(jù)的最大內(nèi)存緩沖區(qū)大小。和MyISAM存儲引擎不同，MyISAM的key_buffer_size只緩存索引鍵，而innodb_buffer_pool_size卻是同時為數(shù)據(jù)塊和索引塊 做緩存，這個特征和Oracle是一樣的，這個值設(shè)得越高，訪問表中數(shù)據(jù)需求的I/O就越少。在一個專用的數(shù)據(jù)庫服務(wù)器，可以設(shè)置這個參數(shù)達(dá)機(jī)器物理內(nèi)存的80%，我現(xiàn)在一般的做法是配置成物理內(nèi)存的 1/4，比如8G內(nèi)存的生產(chǎn)數(shù)據(jù)庫，我一般會配置成2G左右。
四、測試了很長一段時間的MySQL的負(fù)載均衡，最后綜合了老男孩和其它技術(shù)高手的意見，最終決定還是用LVS+Keepalived來作為MySQL的負(fù)載均衡，這是因為后端機(jī)器超過10臺時，LVS的性能還是最好的；如果在3-5臺左右，HAProxy也可以很輕松的搞定工作。
五、大家都很清，磁盤I/O總會成為數(shù)據(jù)庫的性能瓶頸，這時候我們應(yīng)該如何在生產(chǎn)環(huán)境下選擇合適的RAID級別呢？
1、如果數(shù)據(jù)讀寫都很頻繁，可靠性要求也很高，最好選擇RAID10；
2、如果數(shù)據(jù)讀很頻繁，寫相對較少，對可靠性有一定要求，可以選擇RAID5；
3、如果數(shù)據(jù)讀寫都很頻繁，但可靠性要求不高，可以選擇RAID0。
4、對于核心業(yè)務(wù)的數(shù)據(jù)庫主從同步，建議從機(jī)的備份時間往后延遲一段時間，通常的做法是延遲一天左右。