mysql 日誌文件（轉於個人同窗和你們共同分享）

因爲最近碰到一個日誌清理的問題，因此就花時間寫了這篇文章，嚴格來講只是學習筆記。

1.通用日誌文件

默認安裝狀況下不開啓，即不會生成這個文件，須要手工開啓，可直接在命令行中設置：set global general_log = ON。即時生效。重啓MySQL服務後，會關閉，需從新啓動。

也可在配置文件my.ini中設置：general_log=on。這樣每次啓動MySQL服務都會自動啓動。

這樣MySQL就會在data目錄下建立一個和你計算機同名的日誌文件：計算機名-PC.log。

之後你對MySQL作的任何操做，都會被記錄到這個日誌文件中。

2.二進制日誌文件

默認安裝狀況下不開啓，即不會生成這個文件，須要手工開啓，在配置文件my.ini中的[mysqld]後面加入：log_bin=binary_log。這裏的binary_log爲二進制文件名。

這樣MySQL就會在data目錄下建立以下兩個文件：binary_log.000001和binary_log.index。

之後對MySQL表作的任何更新，都會被記錄裏到這個日誌文件中。

當在data目錄下手工刪除了某些二進制日誌文件時，必定要同時刪除binary_log.index裏面的對應記錄，不然mysql服務將沒法啓動。

可在命令行中經過 show binlog events in ‘binary_log.000001’查看：

也可經過mysqlbinlog命令查看，先在dos下進入data目錄而後輸入：mysqlbinlog binary_log.000001。

mysqlbinlog binary_log.000001 > Jin.txt可輸出到txt文件方便查看。

重啓MySQL後，將會在data目錄下從新生成一個新的日誌文件，如原來的是binary_log.000001，那麼重啓後會生成binary_log.000002文件，也便是每次重啓後都會按文件後面的數字遞增生成一個新文件。

flush logs命令可當即生成一個最新的二進制文件，並將後面的更新操做記錄其中。但這樣貌似會出現一個問題：通用日誌（general_log）和慢查詢日誌（slow_log）將再也不更新。再也不更新的意思是說，這些操做被存儲在內存中了，要等下次重啓mysql後，纔會從新寫入日誌中。

    

       因此在使用flush logs命令的時候須要很是當心，由於若是在執行了flush logs命令後，後面產生的通用日誌（general_log）和慢查詢日誌（slow_log）很大的話，那麼就會佔用很大的內存。這個只是個人猜想，你們能夠認證一下。

3.慢查詢日誌文件

默認安裝狀況下不開啓，即不會生成這個文件，須要手工開啓，在配置文件my.ini中的[mysqld]後面加入：

# 慢查詢日誌文件

log_slow_queries = slow_queries_log

# 記錄下查詢時間超過10秒的SQL

long_query_time = 10

# 表示記錄下沒有使用索引的查詢SQL               

log-queries-not-using-indexes 

slow_queries_log是慢查詢日誌的文件名，long_query_time爲查詢時間（單位s），大於此時間的查詢都被記錄到該日誌，log-queries-not-using-indexes表示沒有使用索引的查詢，該查詢也會被記錄到該日誌文件下。

這樣MySQL就會在data目錄下建立以下文件：slow_queries_log。

之後符合上面條件的查詢都會被記錄到這個日誌文件中。

4.log_output = table

該選項默認爲log_output = file，即將日誌存入文件中。可設置將日誌存入表中，只需在my.ini文件[mysqld]加入log_output = table，便可將通用查詢日誌（general_log）以及慢查詢（log_slow_queries）日誌分別存入mysql數據庫的general_log和slow_log表中。

但好像在這種模式下沒法存儲二進制文件。

5．經過日誌文件進行增量備份

   在進行增量備份以前，首先咱們須要進行一個全備份，可使用mysqldump命令：

mysqldump -u 用戶名 -p --single-transaction [數據庫名|--all-databases] > 文件名.sql

--single-transaction的意思至關於設置會話的隔離級別爲REPEATABLE-READ，即容許重複讀，保證數據庫的一致性（關於MySQL的隔離級別，可參考我以前寫的文章：http://www.iteye.com/topic/1130108）。

舉個例子，假如如今有下面幾個數據庫：

咱們要對Jin_Liang這個數據庫作一個全備份，那能夠在DOS寫以下命令：

由圖可見，備份完成，咱們將備份文件存儲在了D盤的Jin_Liang_Backup.sql文件下：

打開文件能夠看到，裏面其實都是表的建立命令以及數據的insert語句。

假如咱們如今清空數據庫Jin_Liang裏的全部表（模擬崩潰狀態）：

這時候Jin_Liang裏面的數據已經所有被刪除了，咱們將經過Jin_Liang_Backup.sql來恢復它們，命令如圖所示：

這時候經過mysql命令行客戶端查看：

由圖可見，表已所有恢復。

上面便是mysql數據庫的全備份了，若是想對全部的數據庫都進行備份，那麼只要在上面的mysqldump命令中選擇—all-databases便可。但這有一個缺點，那就是咱們必須先手工建立數據庫，固然咱們在用mysqldump命令的時候可加入--add-drop-database選項，這樣就不須要手工建立數據庫了。

PS: 這裏還有一些頗有用的命令：

只導出一個表：

       mysqldump -u 用戶名 -p 數據庫名 表名> 文件名.sql

只導出數據庫的表結構：

       mysqldump -u 用戶名 -p -d --add-drop-table 數據庫名 >文件名.sql

      -d 沒有數據 --add-drop-table 在每一個create語句以前增長一個

那下面就開始介紹如何經過二進制日誌文件作增量備份。

首先先看下data目錄下的日誌文件有哪些：

如圖所示，有四個二進制日誌文件：binary_log.00000一、binary_log.00000二、binary_log.000003和binary_log.000004；一個錯誤日誌文件：LilyZhang-PC.err；一個通用日誌文件：LilyZhang-PC.log；一個慢查詢日誌文件：slow_queries.log；還有兩個mysql默認的日誌文件：ib_logfile0和ib_logfile1。

固然咱們只須要二進制日誌文件。

首先咱們須要作flush logs操做，從新生成一個新的二進制日誌文件，以便把後面的操做都記錄其中：

而後查看data目錄，可見新生成了binary_log.000005二進制日誌文件。

這時候咱們更新一條記錄：

查看binary_log.000005文件：

由圖可見，該更新操做已被記錄到binary_log.000005文件中。

咱們把binary_log.000005導出到txt文件方便查看：

打開binary_log.000005.txt文件，如圖所示：

裏面記錄了前面的更新操做。因此咱們只要根據該操做反向操做便可恢復到以前的狀態。

從binary_log.000005.txt文件的內容上看，裏面記錄的實際上是重作日誌，也便是說當數據庫崩潰時，咱們能夠根據其來從新提交【以前所作的更新】，固然前提是咱們作了全備份，而且經過這個全備份文件恢復了備份前的數據，以保證查詢條件存在。

而增量備份的意思是，咱們在作了一次全備份之後，後面咱們只要備份那些新更新的數據便可。而二進制日誌文件中，保存的便是後面的更新操做，咱們只要將其取出重執行一遍，便可恢復到以前的狀態。因此，咱們在作了一次全備份後，後面的備份咱們只要備份二進制日誌文件便可。

如今咱們來模仿經過二進制日誌文件如何恢復數據庫。首先咱們將數據庫Jin_Liang刪除，以模仿崩潰狀態：

而後重建數據庫：

經過全備份恢復：

這時候能夠看到表已恢復：

但查看classes表，此時的數據不是最新的，由於咱們以前有作更新：

Sql代碼

1. update classes set class_name = 'Jin' where class_name = 'Jin_Liang' 

update classes set class_name = 'Jin' where class_name = 'Jin_Liang'

此時咱們就能夠經過二進制日誌文件來重作這個操做，假設咱們前面在作增量備份時，將binary_log.000005備份到了old_logs目錄下，那麼只要作以下操做便可恢復：

此時查看classes表：

class_name中Jin_Liang已更新爲Jin。