利用mysql日誌文件的簡單介紹

本文目錄一覽：

• 1、如何查看mysql數據庫操作記錄日誌？
• 2、如何通過mysql的日誌恢複數據庫 加急求救
• 3、如何開啟mysql的日誌或如何查看 mysql的日誌文件
• 4、使用mysqlbinlog二進制日誌文件 導出
• 5、mysql日誌文件怎麼用？
• 6、mysql中如何用mysqlbinlog工具將日誌文件生成txt文件出來分析

如何查看mysql數據庫操作記錄日誌？

有時候我們會不小心對一個大表進行了 update，比如說寫錯了 where 條件……

此時，如果 kill 掉 update 線程，那回滾 undo log 需要不少時間。如果放置不管，也不知道 update 會持續多久。

那我們能知道 update 的進度么？

實驗

我們先創建一個測試數據庫：

快速創建一些數據：

連續執行同樣的 SQL 數次，就可以快速構造千萬級別的數據：

查看一下總的行數：

我們來釋放一個大的 update：

然後另起一個 session，觀察 performance_schema 中的信息：

可以看到，performance_schema 會列出當前 SQL 從引擎獲取的行數。

等 SQL 結束後，我們看一下 update 從引擎總共獲取了多少行：

可以看到該 update 從引擎總共獲取的行數是表大小的兩倍，那我們可以估算：update 的進度 = (rows_examined) / (2 * 錶行數)

?小貼士

information_schema.tables 中，提供了對錶行數的估算，比起使用 select count(1) 的成本低很多，幾乎可以忽略不計。

那麼是不是所有的 update，從引擎中獲取的行數都會是表大小的兩倍呢？這個還是要分情況討論的，上面的 SQL 更新了主鍵，如果只更新內容而不更新主鍵呢？我們來試驗一下：

等待 update 結束，查看 row_examined，發現其剛好是表大小：

那我們怎麼準確的這個倍數呢？

一種方法是靠經驗：update 語句的 where 中會掃描多少行，是否修改主鍵，是否修改唯一鍵，以這些條件來估算係數。

另一種方法就是在同樣結構的較小的表上試驗一下，獲取倍數。

這樣，我們就能準確估算一個大型 update 的進度了。

如何通過mysql的日誌恢複數據庫 加急求救

1、首先確定my.ini(Win系統)或my.cnf(Linux系統)是否有如下配置

[mysqld]

log-bin=mysql-bin

等號後面是文件名或者路徑加文件名。

或者

用命令看是否開啟binlog配置：

mysql show master logs;

mysql show binlog events g;

2、提供故障時點描述信息

3、如果開啟了binglog那就可以按故障還原點或者時間點進行還原操作了

mysqlbinlog –start-position=

mysqlbinlog –start-datetime=

這裡語法是進一步查詢的線索，不知道你是什麼OS、開發還是生產庫？不能亂指揮。

【備份：做故障還原及數據恢復前切忌做好備份(數據文件以及日誌文件)】

如何開啟mysql的日誌或如何查看 mysql的日誌文件

mysql有以下幾種日誌：

錯誤日誌： -log-err

查詢日誌： -log

慢查詢日誌: -log-slow-queries

更新日誌: -log-update

二進制日誌： -log-bin

在mysql的安裝目錄下，打開my.ini,在後面加上上面的參數，保存後重啟mysql服務就行了。

例如：#Enter a name for the binary log. Otherwise a default name will be used.

#log-bin=#Enter a name for the query log file. Otherwise a default name will be used.

#log=#Enter a name for the error log file. Otherwise a default name will be used.

log-error=#Enter a name for the update log file. Otherwise a default name will be used.

#log-update=

上面只開啟了錯誤日誌，要開其他的日誌就把前面的「#」去掉

查看命令：①show variables like ‘log_%’;查看所有的log命令

②show variables like ‘log_bin’;查看具體的log命令

使用mysqlbinlog二進制日誌文件 導出

 查看MySQL是否開啟binlog(進mysql操作)

 show variables like ‘log_bin%’;

2. 查詢binlog文件名

   show master status;

路徑一般在安裝的mysql/data 下

進入 mysqlbinlog 運行文件目錄 一在mysql/bin下

執行 

 mysqlbinlog –no-defaults ../data/mysql-bin.000012 b.log

1、查詢時間段內日誌的執行內容

mysqlbinlog –start-datetime=’2018-01-08 02:01:00′ –stop-datetime=’2018-01-08 02:30:10′ -d test /var/lib/mysql/mysql-bin.000170 -v

2、查詢時間段內日誌中執行的刪除語句

mysqlbinlog –start-datetime=’2018-01-08 02:01:00′ –stop-datetime=’2018-01-08 02:30:10′ -d test /var/lib/mysql/mysql-bin.000170 -v|grep DELETE -A 5

3、統計時間段內日誌中執行的刪除語句

mysqlbinlog –start-datetime=’2018-01-08 02:01:00′ –stop-datetime=’2018-01-08 02:30:10′ -d test /var/lib/mysql/mysql-bin.000170 -v|grep DELETE |wc -l

mysql日誌文件怎麼用？

my.cnf 這個mysql日誌分：錯誤日誌，二進制日誌，慢查詢日誌，轉儲日誌，每一種都有不同的作用，查看全局變量，顯示為on即為開啟，顯示為off即為關閉，具體怎麼用，不是一言兩語能說清楚的。建議去51cto里查看相關技術博客

mysql中如何用mysqlbinlog工具將日誌文件生成txt文件出來分析

MySQL 的 Binlog 記錄著 MySQL 數據庫的所有變更信息，了解 Binlog 的結構可以幫助我們解析Binlog，甚至對 Binlog 進行一些修改，或者說是「篡改」，例如實現類似於 Oracle 的 flashback 的功能，恢復誤刪除的記錄，把 update 的記錄再還原回去等。本文將帶您探討一下這些神奇功能的實現，您會發現比您想像地要簡單得多。本文指的 Binlog 是 ROW 模式的 Binlog，這也是 MySQL 8 里的默認模式，STATEMENT 模式因為使用中有很多限制，現在用得越來越少了。

Binlog 由事件（event）組成，請注意是事件（event）不是事務（transaction），一個事務可以包含多個事件。事件描述對數據庫的修改內容。

現在我們已經了解了 Binlog 的結構，我們可以試着修改 Binlog 里的數據。例如前面舉例的 Binlog 刪除了一條記錄，我們可以試着把這條記錄恢復，Binlog 裏面有個刪除行（DELETE_ROWS_EVENT）的事件，就是這個事件刪除了記錄，這個事件和寫行（WRITE_ROWS_EVENT）的事件的數據結構是完全一樣的，只是刪除行事件的類型是 32，寫行事件的類型是 30，我們把對應的 Binlog 位置的 32 改成 30 即可把已經刪除的記錄再插入回去。從前面的 「show binlog events」 裏面可看到這個 DELETE_ROWS_EVENT 是從位置 378 開始的，這裡的位置就是 Binlog 文件的實際位置（以位元組為單位）。從事件（event）的結構裏面可以看到 type_code 是在 event 的第 5 個位元組，我們寫個 Python 小程序把把第383（378+5=383）位元組改成 30 即可。當然您也可以用二進制編輯工具來改。

找出 Binlog 中的大事務

由於 ROW 模式的 Binlog 是每一個變更都記錄一條日誌，因此一個簡單的 SQL，在 Binlog 里可能會產生一個巨無霸的事務，例如一個不帶 where 的 update 或 delete 語句，修改了全表裏面的所有記錄，每條記錄都在 Binlog 裏面記錄一次，結果是一個巨大的事務記錄。這樣的大事務經常是產生麻煩的根源。我的一個客戶有一次向我抱怨，一個 Binlog 前滾，滾了兩天也沒有動靜，我把那個 Binlog 解析了一下，發現裏面有個事務產生了 1.4G 的記錄，修改了 66 萬條記錄！下面是一個簡單的找出 Binlog 中大事務的 Python 小程序，我們知道用 mysqlbinlog 解析的 Binlog，每個事務都是以 BEGIN 開頭，以 COMMIT 結束。我們找出 BENGIN 前面的 「# at」 的位置，檢查 COMMIT 後面的 「# at」 位置，這兩個位置相減即可計算出這個事務的大小，下面是這個 Python 程序的例子。

切割 Binlog 中的大事務

對於大的事務，MySQL 會把它分解成多個事件（注意一個是事務 TRANSACTION，另一個是事件 EVENT），事件的大小由參數 binlog-row-event-max-size 決定，這個參數默認是 8K。因此我們可以把若干個事件切割成一個單獨的略小的事務

ROW 模式下，即使我們只更新了一條記錄的其中某個字段，也會記錄每個字段變更前後的值，這個行為是 binlog_row_image 參數控制的，這個參數有 3 個值，默認為 FULL，也就是記錄列的所有修改，即使字段沒有發生變更也會記錄。這樣我們就可以實現類似 Oracle 的 flashback 的功能，我個人估計 MySQL 未來的版本從可能會基於 Binlog 推出這樣的功能。

了解了 Binlog 的結構，再加上 Python 這把瑞士軍刀，我們還可以實現很多功能，例如我們可以統計哪個表被修改地最多？我們還可以把 Binlog 切割成一段一段的，然後再重組，可以靈活地進行 MySQL 數據庫的修改和遷移等工作。