1 MySQL日志

1.1 錯誤日志

文件名：可用–log-error[=file_name]指定，否則默認(rèn)使用hostname.err

內(nèi)容：記錄mysqld啟動和停止時，以及服務(wù)器發(fā)生任何嚴(yán)重錯誤時記錄相關(guān)信息

1.2 二進(jìn)制日志

文件名：也是binlog(邏輯日志)，可用–log-bin[=file_name] 指定，默認(rèn)為主機(jī)名

內(nèi)容：包含了所有更新了或者潛在更新了數(shù)據(jù)的所有語句，語句以“事件”的形式保存，描述數(shù)據(jù)更改文件位置和格式

查看日志：

mysqlbinlog log-file

刪除日志：

#刪除所有的binlog日志，新日志從頭開始編號
RESET MASTER
#刪除mysql-bin.010之前的所有日志
PURGE MASTER LOGS TO 'mysql-bin.010'
#刪除2022.5.1之前的binlog日志
purge master logs before '2022-05-01 08:00:00';

1.3 查詢?nèi)罩?/h4>

文件名：使用–log指定，默認(rèn)hostname.log

內(nèi)容：記錄客戶端所有查詢語句記錄，在二進(jìn)制日志不存在查詢語句記錄

1.4 慢查詢?nèi)罩?/h4>

文件名：使用–log-slow-querie指定，默認(rèn)*-slow.log，寫入data目錄

內(nèi)容：記錄執(zhí)行時間超過long_query_time秒的SQL查詢?nèi)罩疚募?/p>

其它選項：–log_slow_admin_statements：表示將慢管理語句，如OPTIMIZE TABLE、ANALYZE TABLE和ALTER TABLE寫入慢查詢語句

1.5 通用查詢?nèi)罩?/h4>

查看：show variables like '%general_log%';

執(zhí)行SQL命令 set global general_log=on; 開啟

文件：默認(rèn)存放在data目錄下hostname.log文件

內(nèi)容：記錄客戶端的所有查詢行為

1.6 中繼日志

文件：默認(rèn)文件名hostnamet-relay-bin，存放在data目錄下

功能：從服務(wù)器I/O線程將主服務(wù)器的二進(jìn)制日志讀取過來記錄到從服務(wù)器本地文件，然后從服務(wù)器SQL線程會讀取relay-log日志的內(nèi)容并應(yīng)用到從服務(wù)器，從而使從服務(wù)器和主服務(wù)器的數(shù)據(jù)保持一致

參數(shù)：show variables like '%relay%';

• max_relay_log_size
  • relay log 允許的最大值，如果該值為0，則默認(rèn)值為 max_binlog_size (1G)
  • 如果不為0，則 max_relay_log_size 則為最大的relay_log文件大小
• relay_log
  • 定義 relay_log 的位置和名稱，如果值為空，則默認(rèn)位置在數(shù)據(jù)文件的目錄
• relay_log_index
  • 定義 relay_log 索引的位置和名稱，記錄有幾個 relay_log 文件，默認(rèn)為2個
• relay_log_info_file
  • 定義 relay-log.info 的位置和名稱，relay-log.info 記錄 master 主庫的 binary_log 的恢復(fù)位置和 從庫 relay_log 的位置
• relay_log_purge
  • 是否自動清空中繼日志，默認(rèn)值為1(啟用)
• relay_log_recovery
  • 當(dāng)slave從庫宕機(jī)后，假如relay-log損壞了，導(dǎo)致一部分中繼日志沒有處理，則自動放棄所有未執(zhí)行的relay-log，并且重新從master上獲取日志，這樣就保證了relay-log的完整性。默認(rèn)情況下該功能是關(guān)閉的，將relay_log_recovery的值設(shè)置為 1時，可在slave從庫上開啟該功能，建議開啟
• sync_relay_log
  • 當(dāng)設(shè)置為1時，slave的I/O線程每次接收到master發(fā)送過來的binlog日志都要寫入系統(tǒng)緩沖區(qū)，然后刷入relay log中繼日志里，這樣是最安全的，因為在崩潰的時候，你最多會丟失一個事務(wù)，但會造成磁盤的大量I/O
  • 當(dāng)設(shè)置為0時，并不是馬上就刷入中繼日志里，而是由操作系統(tǒng)決定何時來寫入，雖然安全性降低了，但減少了大量的磁盤I/O操作。這個值默認(rèn)是0，可動態(tài)修改
• sync_relay_log_info
  • 這個參數(shù)和 sync_relay_log 參數(shù)一樣

1.7 審計日志

內(nèi)容：企業(yè)版自帶功能，社區(qū)版需使用audit審計插件完成數(shù)據(jù)庫審計工作

開啟步驟：

• 下載插件：https://github.com/mcafee/mysql-audit

• 查看插件功能是否開啟： show variables like "%audit%";

• 開啟插件功能：set global audit_json_file=1;

  注意，使用此方法開啟對global全局變量的設(shè)置僅對于新開啟的會話才是有效的，對已經(jīng)開啟的會話不生效，參數(shù)最終需持久化到my.cnf配置文件中

• 開啟后，在MySQL數(shù)據(jù)目錄下會多出一個mysql-audit.json審計日志

2 InnoDB日志

2.1 重做日志 (Redo Log)

文件：默認(rèn)情況下，對應(yīng)的物理文件位于數(shù)據(jù)庫的data目錄下的ib_logfile1&ib_logfile2

內(nèi)容：物理日志，記錄物理數(shù)據(jù)頁面的修改信息，redo log順序?qū)懭雛edo log file物理文件中

重做日志有一個緩沖區(qū)Innodb_log_buffer，InnoDB優(yōu)先將重做日志寫入緩沖區(qū)，日志寫盤通常有三種方式：

• Master Thread 每秒一次執(zhí)行刷新Innodb_log_buffer到重做日志文件

• 每個事務(wù)提交時會將重做日志刷新到重做日志文件。

• 當(dāng)重做日志緩存可用空間 少于一半時，重做日志緩存被刷新到重做日志文件

因此，重做日志的寫盤，并不一定是隨著事務(wù)的提交才寫入重做日志文件的，而是隨著事務(wù)的開始逐步開始的，這可以很好地解釋再大的事務(wù)的提交（commit）的時間也是很短暫的

事務(wù)產(chǎn)生的重做日志，通過innodb_flush_log_at_trx_commit參數(shù)控制：

• 設(shè)置為 0 的時候，表示不寫入buffer，直接每秒寫入到redo file中，但mysql 崩潰會丟失1s數(shù)據(jù)
• 設(shè)置為 1 的時候，表示每次事務(wù)提交時都將 redo log 直接持久化到磁盤
• 設(shè)置為 2 的時候，表示每次事務(wù)提交時都只是把 redo log 寫到 page cache，由OS處理回寫磁盤操作，OS宕機(jī)會丟失數(shù)據(jù)

2.2 回滾日志(Undo Log)

文件：邏輯日志，記錄在表空間中

• MySQL5.6之前，undo表空間位于共享表空間的回滾段中，共享表空間的默認(rèn)的名稱是ibdata，位于數(shù)據(jù)文件目錄中

• MySQL5.6之后，undo表空間可以配置成獨(dú)立的文件，但是提前需要在配置文件中配置，完成數(shù)據(jù)庫初始化后生效且不可改變undo log文件的個數(shù)

內(nèi)容：記錄數(shù)據(jù)的邏輯變化，一條INSERT會對應(yīng)一條DELETE的undo log，發(fā)生錯誤時能夠恢復(fù)到事務(wù)之前的數(shù)據(jù)狀態(tài)

undo log是MVCC(多版本并發(fā)控制)實現(xiàn)的關(guān)鍵