本文由秀依林楓提供友情贊助，首發於爛泥行天下。
1、基礎知識
日志是把數據庫的每一個變化都記載到一個專用的文件裡，這種文件就叫做日志文件。mysql默認只開啟錯誤日志，因為過多的日志將會影響系統的處理性能。
在mysql5.0以前版本支持文本格式和二進制格式的日志，但是在mysql5.0後版本就只支持二進制格式的日志。因為二進制日志在性能、信息處理等方面有更多的優點。
2、啟用mysql二進制日志
mysql二進制日志由配置文件my.cnf的log-bin選項負責啟用的。
mysql服務器默認會在數據根目錄創建兩個新文件：XXX-bin.000001和XXX-bin.index。若配置選項沒有給出文件名，mysql將使用mysql-bin來命名這兩個文件，其中.index文件包含一份完整的日志文件清單。如下：
cat /etc/my.cnf
ll /usr/local/mysql/data/
cat /usr/local/mysql/data/mysql-bin.index
mysql會把用戶對所有數據庫的內容和結構的修改情況記入XXX-bin.n文件，但是不會記錄SELECT和沒有實際更新的UPDATE語句。
當然我們也可以同過相關命令查詢，mysql是否已經開啟binlog日志。如下：
show variables like 'log_%';
3、binlog日志文件的生成
當mysql停止或重啟時，服務器會把日志文件記入下一個日志文件，mysql會在重啟時生成一個新的日志文件，文件序號依次遞增。
如果日志文件超過max_binlog_size（在my.cnf文件中配置）系統變量配置的上限時，也會生成新的日志文件。
除此之外，如果在mysql命令中執行flush logs命令也會生成新的日志文件。
4、查看系統中的binlog日志
查看系統中的binlog日志，使用show master logs命令。如下：
show master logs;
5、查看binlog日志文件
mysql提供了mysqlbinlog命令來查看日志文件，在記錄每條變更日志的時候，日志文件都會把當前時間給記錄下來，以便進行數據庫恢復。如下：
mysqlbinlog mysql-bin.000001| more
6、使用binlog日志進行數據庫恢復
如果遇到災難事件，應該用最近一次制作的完整備份恢復數據庫，然後使用備份之後的binlog日志件把數據庫恢復到最接近現在的可用狀態。
使用binlog日志進行恢復時需要依次進行，即最早生成的日志文件要最先恢復。恢復數據的命令格式如下：
mysqlbinlog xxx-bin.000001|mysql -u root –p password dataname
有關使用binlog進行數據庫的恢復，我會以後的文章進行詳細介紹。
7、binlog命令行參數詳解
log-bin [=file_name] 此參數表示啟用binlog日志功能，並可以定制路徑名稱，默認為mysql-bin。
binlog_format 此參數配置binlog的日志格式，默認為mixed。
max_binlog_size此參數配置binlog的日志最大值，最大和默認值是1GB。
max_binlog_cache_size此參數表示binlog使用最大內存的數。
binlog-do-db=db_name 此參數表示只記錄指定數據庫的二進制日志。
binlog-ignore-db=db_name此參數表示不記錄指定的數據庫的二進制日志。
expire_logs_days 此參數表示binlog日志保留的時間，默認單位是天。
my.cnf配置文件有關binlog配置如下：
cat /etc/my.cnf |grep -v ^#|grep -v ^$
8、刪除binlog日志
8.1刪除部分binlog日志
刪除binlog部分日志，我們可以日志名稱和日志生成的時間來進行刪除。刪除命令如下：
purge {master|binary} logs to 'log_name';
根據日志名稱刪除，只刪除log_name之前的日志，log_name本身不會被刪除。
通過上圖我們可以看到，mysql-bin.000003之前的日志已經被全部刪除。
purge {master|binary} logs before 'date’;
根據日志生成的時間刪除，只刪除date之前的日志，date本身不會被刪除。
8.2刪除全部binlog日志
刪除之前所有的binlog日志，並重新生成新的binlog，後綴從000001開始。使用命令：
reset master;
這個是在mysql的配置文件中設置的~~~設定開啟二進制日志~~~
The danger is simple: they don't work the way you think they do. Consider the following scenario: you set binlog-ignore-db to "garbage" so data in the garbage database (which doesn't exist on the slave) isn't replicated. (I'll come back to this in a second, so if you already see the problem, don't rush to the comment form.)Now you do the following:現在做下面的事情:$ mysqlmysql delete from garbage.junk;mysql use garbage;mysql update production.users set disabled = 1 where user = "root";You just broke replication, twice. Once, because your slave is going to execute the first query and there's no such table "garbage.junk" on the slave. The second time,silently, because the update to production.users isn't replicated, so now the root user isn't disabled on the slave.復制會broke2次, 第一次，因為 slave嘗試著去之西你給第一條語句，但是slave上並沒有這樣的表"garbage.junk" , 第二次, 隱含的, 因為 對 production.users不會被 復制,因為 root帳號並沒有在slave上被禁用掉.Why? Because binlog-ignore-db doesn't do what you think. The phrase I used earlier, "data in the garbage database isn't replicated," is a fallacy. That's not what it does. In fact, itfilters out binary logging for statements issued from connections whose default database is "garbage."In other words, filtering is not based on the contents of the query -- it is based on what database you USE.The other configuration options I mentioned work similarly. The binlog-do-db and binlog-ignore......余下全文>>
