MySQL日誌服務 一 服務日誌

mysql中包含了許多日誌服務，這些日誌分別記錄了使用者對資料庫的不同的操作，以及mysql的各種狀態和異常，熟悉這些日誌，在自己的資料庫出現問題的時候檢視相關的日誌可以幫助你準確的定位問題，及時解決。

我們先來看一下，mysql都有哪一些日誌：

server層日誌(由mysql自身實現)：

錯誤日誌(error log) : 用於記錄使用者運算元據庫的各種錯誤和警告。

查詢日誌(general query log) : 記錄查詢語句的query_id，以及它們查詢的流程狀態。

二進位制日誌(bin log)：記錄了所有增刪改資料庫的sql。

中繼日誌(relay log)：主從備份時從庫特有的日誌，用來記錄主庫傳輸到從庫的bin-log記錄。

慢查詢日誌(slow query log)：記錄了超過使用者設定時間的資料庫操作。

儲存引擎inodb層日誌：

undo log：記錄了每乙個事務的回滾段。

redo log：記錄了日誌從begin開始到commit結束，中間所有對資料庫操作。

inodb實現的undo和redo日誌主要是用於保證事務的正常執行，其中原理稍微有一些複雜，會用專門的篇幅來講，現在我們先來**一下server的這些比較常見的日誌。

mysql服務搭建完成的時候，系統會自動生成乙個錯誤日誌檔案，以windows下的mysql為例，檔名為：win7-20180402nj.err

如果想要檢視自己的mysql錯誤日誌路徑，使用查詢語句show variables like 'log_error';

結果如圖：

value的值就是當前錯誤日誌的路徑。

然後我們尋著這個路徑去找到錯誤日誌，開啟它，看看它都記錄了一些什麼內容：

以我的error log 為例，可以看到其中記錄了兩個warning警告。當你遇到了諸如資料庫連線錯誤等等一些系統性的問題時，你可以嘗試來看一下error log，mysql會將詳盡的原因告訴你。

查詢日誌是相對用的比較少的乙個日誌，mysql服務啟動時預設是沒有查詢日誌的。使用sql語句show variables like "%general_log%";檢視當前的查詢日誌狀態。

可以看到預設是off狀態，如果想要開啟查詢日誌，使用sql語句set global general_log= on;

那麼再執行查詢的時候，日誌會出現在上圖所示的路徑中。查詢日誌的內容如下：

記錄了每一條select語句的狀態流。

中繼日誌與二進位制bin-log日誌一樣，由一組編號檔案（包含描述資料庫更改的事件）和乙個索引檔案（包含所有已使用中繼日誌檔案的名稱）組成。中繼日誌檔案的預設位置是資料目錄。

主要是從庫用來記錄主庫tp過來的bin-log操作日誌。

慢查詢日誌記錄了超過使用者設定的時間的資料庫操作記錄(需要注意的是，並非只有查詢語句會被記錄，任何超過設定時間的增刪改操作也會被記錄。)

開啟慢查詢的sql語句：set global slow_query_log=on;

set long_query_time=1; #當前生效

慢查詢日子還可以記錄沒有使用索引的查詢語句，mysql預設沒有開啟，通過下面的sql查詢是否開啟了這個功能：

show global variables like '%log_queries_not_using_indexes%';

同樣，只需要使用sql:set log_queries_not_using_indexes=on;就可以開啟。

慢查詢日誌是乙個比較重要的日誌，相信使用過mysql的同學都分析過慢查詢日誌，當然慢查詢日誌只能幫你記錄你的業務中可能存在設計問題的sql語句，可以幫你發現你專案中的優化點，但是如果想要慢查詢日誌對你有足夠大的作用，你還需要精通mysql的索引設計與優化，這樣與慢查詢日誌配合起了才如虎添翼。

慢查詢日誌雖然有用，但是它並非是重點，重點是你需要精通mysql的索引知識，才能更好的你用慢查詢日誌。關於mysql的索引之後也會講到，也是乙個很複雜的知識點，也是mysql技術的重中之重，這裡先略過。

bin-log日誌放在最後面，是因為它是我個人認為最重要的乙個日誌，對於大公司來說，有專門的dba來處理這些問題，做為乙個服務端開發，懂這些知識可以讓你更好的和dba交流優化出更完美的系統，但是不懂也沒有特別大的影響。

而對於小公司來說，沒有dba的支援，你不知道上面的那些日誌，最多你錯誤找慢一點，sql稍微寫的爛一點，小公司也沒有高併發場景來講，哪怕乙個1s的查詢也不會有特別的大影響。

恰好你又不懂bin-log日誌如何使用，那這個服務就遠不止癱瘓一會而已。可能需要等你花半天甚至一天來搞定這些錯誤的資料，萬一這些資料還涉及到money，你可能直接到前台領盒飯了。

所以，一旦資料庫錯誤無法恢復，後果遠比你的系統阻塞一段時間要來的嚴重！

既然這麼嚴重，那麼萬一不小心真的搞錯了，該怎麼辦呢？不要急，mysql在設計的時候，早就想好了這個問題，這種時候bin-log日誌就要閃亮登場了。

mysql預設的第乙個bin-log檔案，與其他日誌檔案在同乙個目錄下。如下圖，binlog.index則記錄了當前binlog檔案的索引，索引binlog.index中應該只記錄了binlog.000001一行

我們先來看看bin-log日誌裡面記錄了一些什麼，由於bin-log是二進位制檔案，所以你直接找到檔案開啟看到的都是0101 0101 1100這種內容，我們通過sql來觀察：

show binlog events in 'binlog.000001'

其中binlog.000001是檔名

我擷取了一段完整的事務提交，從begin開始到commit結束。有個很重要的屬性就是pos這個字段，mysql的每個操作，在bin-log內都會記錄乙個postion(位置)，bin-log日誌可以根據這個postion將資料庫恢復到這個操作執行時候的狀態。

mysql提供了乙個名為mysqlbinlog的指令碼，可以用來執行bin-log日誌相關的操作。

根據postion來恢復資料

shell>mysqlbinlog.exe --no-defaults --start-position=1512 --stop-position=1744 -d spring_demo binlog.000002 > /home/test1.sql

根據時間來恢復資料

shell>mysqlbinlog.exe --no-defaults mysql-bin.000002 --start-datetime=『2019-12-25 11:15:21』 --stop-datetime=『2019-12-25 11:17:22』 > /home/test1.sql

在準備恢復之前，我建議先使用flush logs重新整理bin-log日誌，會產生乙個新的bin-log日誌檔案來記錄，之前的檔案不會刪除，所以你可以直接開啟之前的binlog.000001檢視記錄，與show binlog events in 'binlog.000001'顯示的內容是一致的

基礎元件 統一服務日誌切面

dependency groupid org.springframework.boot groupid artifactid spring boot starter aop artifactid dependency author gabriel date 2020 1 28 22 08 descr...

日誌服務 elk

我們使用微服務開發，一般都會進入集群部署場景，日誌檔案就會散落到多個伺服器上，這時我們要檢視日誌時，都要到對應的伺服器上看，這樣子很麻煩，所以得把日誌全部歸到乙個地方去，統一管理，這樣就方便查詢等了。不需要到處跑。這裡主要用到的是elk系統，對應elasticsearch logstash kiba...

rsyslog日誌服務

linux系統日誌分析 rsyslog日誌服務簡介 日誌的概念好理解，日誌作用可用於排障和追溯審計的等 rsyslog 是乙個c s架構的服務，可監聽於某套接字，幫其它主機記錄日誌資訊，rsyslog可以理解為增強版的syslog，在syslog的基礎上擴充套件了很多其他功能，如資料庫支援 mysq...