說(shuō)明：

開(kāi)啟MySQL binlog日志的服務(wù)器，如果不設(shè)置自動(dòng)清理日志，默認(rèn)binlog日志一直保留著，時(shí)間一長(zhǎng)，服務(wù)器磁盤空間被binlog日志占滿，導(dǎo)致MySQL數(shù)據(jù)庫(kù)出錯(cuò)。

使用下面方法可以安全清理binlog日志

一、沒(méi)有主從同步的情況下清理日志

mysql -uroot -p123456 -e 'PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ),INTERVAL 5 DAY)';

#mysql 定時(shí)清理5天前的binlog

mysql -u root -p  #進(jìn)入mysql 控制臺(tái)

reset master;  #重置binlog

二、MySQL主從同步下安全清理binlog日志

1、mysql  -u root -p   #進(jìn)入從服務(wù)器mysql控制臺(tái)
show slave status\G;   #檢查從服務(wù)器正在讀取哪個(gè)日志，有多個(gè)從服務(wù)器，選擇時(shí)間最早的一個(gè)做為目標(biāo)日志。
2、進(jìn)入主服務(wù)器mysql控制臺(tái)

show master log;   #獲得主服務(wù)器上的一系列日志
PURGE MASTER LOGS TO 'binlog.000058';   #刪除binlog.000005之前的，不包括binlog.000058
PURGE MASTER LOGS BEFORE '2016-06-22 13:00:00';  #清除2016-06-22 13:00:00前binlog日志
PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);  #清除3天前binlog日志

三、設(shè)置自動(dòng)清理MySQL binlog日志

vi  /etc/my.cnf  #編輯配置

expire_logs_days = 15 #自動(dòng)刪除15天前的日志。默認(rèn)值為0，表示從不刪除。
log-bin=mysql-bin #注釋掉之后，會(huì)關(guān)閉binlog日志
binlog_format=mixed #注釋掉之后，會(huì)關(guān)閉binlog日志

:wq!  #保存退出

擴(kuò)展閱讀：

mysql> help purge;

Name: 'PURGE BINARY LOGS'

Description:

Syntax:

PURGE { BINARY | MASTER } LOGS

{ TO 'log_name' | BEFORE datetime_expr }

The binary log is a set of files that contain information about data

modifications made by the MySQL server. The log consists of a set of

binary log files, plus an index file (see

http://dev.mysql.com/doc/refman/5.5/en/binary-log.html).

The PURGE BINARY LOGS statement deletes all the binary log files listed

in the log index file prior to the specified log file name or date.

BINARY and MASTER are synonyms. Deleted log files also are removed from

the list recorded in the index file, so that the given log file becomes

the first in the list.

This statement has no effect if the server was not started with the

--log-bin option to enable binary logging.

URL: http://dev.mysql.com/doc/refman/5.5/en/purge-binary-logs.html

Examples:

PURGE BINARY LOGS TO 'mysql-bin.010';

PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';

下面是其它網(wǎng)友給出的方法，大家可以參考一下

MYSQL主從復(fù)制(replication)采用 RBR 模式后，binlog的格式為"ROW"，能解決很多原先出現(xiàn)的主鍵重復(fù)問(wèn)題。
在一個(gè)繁忙的master db server上，binlog日志文件增長(zhǎng)速度很快，如果不定時(shí)清除，硬盤空間很快就會(huì)被充滿。
設(shè)置自動(dòng)清理mysql binlog日志，配置my.cnf：

expire_logs_days = 10

在運(yùn)行時(shí)修改：

show binary logs;
show variables like '%log%';
set global expire_logs_days = 10;

清除之前可以采用相應(yīng)的備份策略。

手動(dòng)刪除10天前的MySQL binlog日志：

PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);
show master logs;

MASTER和BINARY是同義詞。

一般情況下，推薦使用MIXED binlog的復(fù)制。http://dev.mysql.com/doc/refman/5.1/en/open-bugs-general.html中的說(shuō)明:Replication uses query-level logging: The master writes the executed queries to the binary log. This is a very fast, compact, and efficient logging method that works perfectly in most cases.

附：關(guān)于MYSQL復(fù)制的幾種模式

從 MySQL 5.1.12 開(kāi)始，可以用以下三種模式來(lái)實(shí)現(xiàn)：
– 基于SQL語(yǔ)句的復(fù)制(statement-based replication, SBR)，
– 基于行的復(fù)制(row-based replication, RBR)，
– 混合模式復(fù)制(mixed-based replication, MBR)。
相應(yīng)地，binlog的格式也有三種：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默認(rèn)的。

在運(yùn)行時(shí)可以動(dòng)態(tài)改動(dòng) binlog的格式，除了以下幾種情況：
. 存儲(chǔ)流程或者觸發(fā)器中間
. 啟用了NDB
. 當(dāng)前會(huì)話試用 RBR 模式，并且已打開(kāi)了臨時(shí)表

如果binlog采用了 MIXED 模式，那么在以下幾種情況下會(huì)自動(dòng)將binlog的模式由 SBR 模式改成 RBR 模式。
. 當(dāng)DML語(yǔ)句更新一個(gè)NDB表時(shí)
. 當(dāng)函數(shù)中包含 UUID() 時(shí)
. 2個(gè)及以上包含 AUTO_INCREMENT 字段的表被更新時(shí)
. 行任何 INSERT DELAYED 語(yǔ)句時(shí)
. 用 UDF 時(shí)
. 視圖中必須要求運(yùn)用 RBR 時(shí)，例如建立視圖是運(yùn)用了 UUID() 函數(shù)

設(shè)定主從復(fù)制模式：
log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"

也可以在運(yùn)行時(shí)動(dòng)態(tài)修改binlog的格式。例如
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';

兩種模式各自的優(yōu)缺點(diǎn)：

SBR 的優(yōu)點(diǎn)：
歷史悠久，技能成熟
binlog文件較小
binlog中包含了所有數(shù)據(jù)庫(kù)修改信息，可以據(jù)此來(lái)審核數(shù)據(jù)庫(kù)的安全等情況
binlog可以用于實(shí)時(shí)的還原，而不僅僅用于復(fù)制
主從版本可以不一樣，從服務(wù)器版本可以比主服務(wù)器版本高
SBR 的缺點(diǎn)：
不是所有的UPDATE語(yǔ)句都能被復(fù)制，尤其是包含不確定操作的時(shí)候。
調(diào)用具有不確定因素的 UDF 時(shí)復(fù)制也可能出疑問(wèn)
運(yùn)用以下函數(shù)的語(yǔ)句也不能被復(fù)制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啟動(dòng)時(shí)啟用了 –sysdate-is-now 選項(xiàng))
INSERT … SELECT 會(huì)產(chǎn)生比 RBR 更多的行級(jí)鎖
復(fù)制須要執(zhí)行 全表掃描(WHERE 語(yǔ)句中沒(méi)有運(yùn)用到索引)的 UPDATE 時(shí)，須要比 RBR 請(qǐng)求更多的行級(jí)鎖
對(duì)于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語(yǔ)句會(huì)阻塞其他 INSERT 語(yǔ)句
對(duì)于一些復(fù)雜的語(yǔ)句，在從服務(wù)器上的耗資源情況會(huì)更嚴(yán)重，而 RBR 模式下，只會(huì)對(duì)那個(gè)發(fā)生變化的記錄產(chǎn)生影響
存儲(chǔ)函數(shù)(不是存儲(chǔ)流程 )在被調(diào)用的同時(shí)也會(huì)執(zhí)行一次 NOW() 函數(shù)，這個(gè)可以說(shuō)是壞事也可能是好事
確定了的 UDF 也須要在從服務(wù)器上執(zhí)行
數(shù)據(jù)表必須幾乎和主服務(wù)器保持一致才行，否則可能會(huì)導(dǎo)致復(fù)制出錯(cuò)
執(zhí)行復(fù)雜語(yǔ)句如果出錯(cuò)的話，會(huì)消耗更多資源

RBR 的優(yōu)點(diǎn)：
任何情況都可以被復(fù)制，這對(duì)復(fù)制來(lái)說(shuō)是最安全可靠的
和其他大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)的復(fù)制技能一樣
多數(shù)情況下，從服務(wù)器上的表如果有主鍵的話，復(fù)制就會(huì)快了很多
復(fù)制以下幾種語(yǔ)句時(shí)的行鎖更少：
* INSERT … SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 沒(méi)有附帶條件或者并沒(méi)有修改很多記錄的 UPDATE 或 DELETE 語(yǔ)句
執(zhí)行 INSERT，UPDATE，DELETE 語(yǔ)句時(shí)鎖更少
從服務(wù)器上采用多線程來(lái)執(zhí)行復(fù)制成為可能
RBR 的缺點(diǎn)：
binlog 大了很多
復(fù)雜的回滾時(shí) binlog 中會(huì)包含大量的數(shù)據(jù)
主服務(wù)器上執(zhí)行 UPDATE 語(yǔ)句時(shí)，所有發(fā)生變化的記錄都會(huì)寫到 binlog 中，而 SBR 只會(huì)寫一次，這會(huì)導(dǎo)致頻繁發(fā)生 binlog 的并發(fā)寫疑問(wèn)
UDF 產(chǎn)生的大 BLOB 值會(huì)導(dǎo)致復(fù)制變慢
不能從 binlog 中看到都復(fù)制了寫什么語(yǔ)句(加密過(guò)的)
當(dāng)在非事務(wù)表上執(zhí)行一段堆積的SQL語(yǔ)句時(shí)，最好采用 SBR 模式，否則很容易導(dǎo)致主從服務(wù)器的數(shù)據(jù)不一致情況發(fā)生
另外，針對(duì)系統(tǒng)庫(kù) mysql 里面的表發(fā)生變化時(shí)的處理準(zhǔn)則如下：
如果是采用 INSERT，UPDATE，DELETE 直接操作表的情況，則日志格式根據(jù) binlog_format 的設(shè)定而記錄
如果是采用 GRANT，REVOKE，SET PASSWORD 等管理語(yǔ)句來(lái)做的話，那么無(wú)論如何 都采用 SBR 模式記錄。
注：采用 RBR 模式后，能處理很多原先出現(xiàn)的主鍵重復(fù)問(wèn)題。實(shí)例:
對(duì)于insert into db_allot_ids select * from db_allot_ids 這個(gè)語(yǔ)句:
在BINLOG_FORMAT=STATEMENT 模式下:
BINLOG日志信息為:
—————————————–
BEGIN
/*!*/;
# at 173
#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
insert into db_allot_ids select * from db_allot_ids
/*!*/;
—————————————–

在BINLOG_FORMAT=ROW 模式下:
BINLOG日志信息為:
—————————————–
BINLOG '
hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;
—————————————–

清理日志步驟
1.查找日志檔案
mysql> show binary logs;
+----------------+-----------+
| Log_name       | File_size |
+----------------+-----------+
| ablelee.000001 | 150462942 |
| ablelee.000002 |       125 |
| ablelee.000003 |       106 |
+----------------+-----------+
2.刪除bin-log(刪除ablelee.000003之前的而沒(méi)有包含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)
 
(刪除的其它格式運(yùn)用!)
　  PURGE {MASTER | BINARY} LOGS TO 'log_name'
　　PURGE {MASTER | BINARY} LOGS BEFORE 'date'
　　用于刪除列于在指定的日志或日期之前的日志索引中的所有二進(jìn)制日志。這些日志也會(huì)從記錄在日志索引文件中的清單中被刪除，這樣被給定的日志成為第一個(gè)。
　　例如：
　　PURGE MASTER LOGS TO 'mysql-bin.010';
　　PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00';
    清除3天前的 binlog
    PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);
　　BEFORE變量的date自變量可以為'YYYY-MM-DD hh:mm:ss'格式。MASTER和BINARY是同義詞。
　　如果您有一個(gè)活性的從屬服務(wù)器，該服務(wù)器當(dāng)前正在讀取您正在試圖刪除的日志之一，則本語(yǔ)句不會(huì)起作用，而是會(huì)失敗，并伴隨一個(gè)錯(cuò)誤。不過(guò)，如果從屬服務(wù)器是休止的，并且您碰巧清理了其想要讀取的日志之一，則從屬服務(wù)器啟動(dòng)后不能復(fù)制。當(dāng)從屬服務(wù)器正在復(fù)制時(shí)，本語(yǔ)句可以安全運(yùn)行。您不需要停止它們。
　　要清理日志，需按照以下步驟：
　　1. 在每個(gè)從屬服務(wù)器上，使用SHOW SLAVE STATUS來(lái)檢查它正在讀取哪個(gè)日志。
　　2. 使用SHOW MASTER LOGS獲得主服務(wù)器上的一系列日志。
　　3. 在所有的從屬服務(wù)器中判定最早的日志。這個(gè)是目標(biāo)日志。如果所有的從屬服務(wù)器是更新的，這是清單上的最后一個(gè)日志。

　　4. 制作您將要?jiǎng)h除的所有日志的備份。（這個(gè)步驟是自選的，但是建議采用。）

　　5. 清理所有的日志，但是不包括目標(biāo)日志