在Mysql/MariaDB的日誌大致分爲下列幾種：
查詢日誌
一般查詢日誌：
慢查詢日誌：
錯誤日誌
二進制日誌
中繼日誌
事務日誌
簡要介紹一下這幾種日誌，日誌對我們分析MySQL服務有着很重要的幫助；
查詢日誌：
一般查詢日誌： 默認關閉，因爲會記錄所有的查詢語句；
MariaDB [(none)]> select @@general_log; +---------------+ | @@general_log | +---------------+ | 0 | +---------------+
慢查詢日誌：默認關閉，建議開啓，在SQL語句調優和MySQL服務器性能分析時具有一定的參考意義；
指的是查詢時間超過服務器參數long_query_time所設定的時間的查詢語句；但是查詢獲取鎖的時間不計入查詢時間考覈內；
MariaDB [(none)]> show global variables like 'long_query_time'; +-----------------+-----------+ | Variable_name | Value | +-----------------+-----------+ | long_query_time | 10.000000 | +-----------------+-----------+
慢查詢日誌可以以兩種形式存放，也受log_output服務器參數的控制；
1. 以文件的形式存放於文件系統中；
2. 以系統表的形式存放於mysql.slow_log表中；
慢查詢日誌的功能開關：
log_slow_queries { ON | OFF }
slow_query_log { ON | OFF }
慢查詢日誌的功能開關，如果兩個開關都在，則修改一個的值，另一個值也隨之改變；
MariaDB [(none)]> select @@log_slow_queries; +--------------------+ | @@log_slow_queries | +--------------------+ | 0 | +--------------------+ 1 row in set (0.00 sec) MariaDB [(none)]> select @@slow_query_log; +------------------+ | @@slow_query_log | +------------------+ | 0 | +------------------+
log_slow_rate_limit = N 慢查詢日誌的記錄頻率；
log_slow_verbosity { ON | OFF } 是否詳細記錄慢查詢日誌的功能開關；
slow_query_log_file /PATH
只有log_output服務器參數的值爲FILE時，此服務器參數纔有效；其值爲慢查詢日誌的存放路徑及文件名稱；默認路徑爲數據目錄(datadir), 文件名爲：HOSTNAME-slow.log；
log_queries_not_using_indexes { ON | OFF }
對於那些沒有使用索引導致的慢查詢是否記錄於慢查詢日誌的功能開關；默認值爲OFF；
測試慢查詢：
MariaDB [(none)]> select sleep(10); +-----------+ | sleep(10) | +-----------+ | 0 | +-----------+
mysql的客戶端工具mysqldumpslow可以幫助分析慢查詢日誌；
常用選項：
-a：在歸類是不使用N代替數字，不使用S代替字符串；
--debug, -d：輸出調試信息，更方便日誌分析；
-t N：僅顯示慢查詢日誌中的前N條慢查詢結果；
--verbose, -v：顯示詳細信息；
-g pattern：通過grep進行select語句的篩選；
[root@master ~]# mysqldumpslow -a -v Reading mysql slow query log from /var/lib/mysql/master-slow.log Count: 1 Time=10.00s (10s) Lock=0.00s (0s) Rows_sent=1.0 (1), Rows_examined=0.0 (0), root[root]@localhost select sleep(10)
錯誤日誌：
可以記錄信息的內容
1.mysqld|mysqld_safe程序啓動或關閉的過程中輸出的信息；
2.mysqld服務運行過程中產生的錯誤信息；
3.時間調度器在運行時產生的信息；
4.在主從架構的MySQL複製模型中，SLAVE服務器的複製線程啓動時產生的信息；
5.可以通過log_warnings的服務器參數控制將"Warning"類的信息記錄於此；
MariaDB [(none)]> select @@log_error; +------------------------------+ | @@log_error | +------------------------------+ | /var/log/mariadb/mariadb.log | +------------------------------+
與錯誤日誌先關的服務器變量參數；
log_error /var/log/mariadb/mariadb.log
開啓錯誤日誌記錄，並定義記錄錯誤日誌的文件路徑及文件名；
log_warnings 1
是否將mysqld運行過程中產生的"Warning"類的信息一併記錄在錯誤日誌文件中的功能開關；
二進制日誌：
二進制日誌包含了引起或可能引起數據變化的事件的信息：如：
insert，update，delete
update和delete語句在執行時根據指定的條件沒有匹配的行；
create，alter，drop
但是諸如select或show這樣的查詢語句，絕對不會被記錄在二進制日誌中；
二進制日誌中的"事件"，包含了引起數據變化或可能引起數據變化的SQL語句或SQL語句的執行結果，也有可能是二者的混合；
1.如果記錄SQL語句，日誌中記錄的數據量比較小，可能產生潛在的結果不一致，比如與時間有關的函數的執行結果；
2.如果記錄SQL語句的執行結果，能夠精確的保存數據結果集，但是可能會導致數據量過於龐大；
到底該如何記錄二進制日誌內容，由一個服務器參數來決定的；
binlog_format STATEMENT
該變量的取值：
STATEMENT：以SQL語句方式記錄二進制日誌；
ROW：以SQL語句在執行之後發送改變的數據行的信息記錄二進制日誌；
MIXED：混合模式，STATEMENT和ROW兩種模式都支持，但是在記錄某個事件時，只能選擇一種格式來記錄，由MySQL自行決定到底使用何種格式；
MariaDB [(none)]> show global variables like 'binlog_format'; +---------------+-----------+ | Variable_name | Value | +---------------+-----------+ | binlog_format | STATEMENT | +---------------+-----------+
二進制日誌的功能：數據重放；
1.主從複製
2.用於數據的增量備份；
MySQL或MariaDB默認並沒有開啓二進制日誌的記錄的功能，如果想要開啓；
1.修改服務器參數：
SET @@GLOBAL.logbin={ ON | OFF | PATH }
2.修改配置文件：
在主配置文件/etc/my.cnf，添加一行
log_bin=/PATH/TO/binlog
注意：
1) MySQL或MariaDB 5.5+中，不支持ON或OFF的開關值，僅支持路徑；
2) 二進制日誌文件的路徑，原則上講，不應該與數據庫存放在同一個存儲設備之上；
可以通過mysql的交互模式查看二進制文件的列表，查看當前正在使用的日誌文件；
MariaDB [(none)]> show master logs; +---------------+-----------+ | Log_name | File_size | +---------------+-----------+ | binlog.000001 | 3478 | | binlog.000002 | 33156 | | binlog.000003 | 1568 | | binlog.000004 | 264 | | binlog.000005 | 264 | | binlog.000006 | 245 | +---------------+-----------+ MariaDB [(none)]> show master status; +---------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------+----------+--------------+------------------+ | binlog.000006 | 245 | | | +---------------+----------+--------------+------------------+
查看某指定的二進制文件中的時間內容：
MariaDB [(none)]> show binlog events in 'binlog.000006'\G *************************** 1. row *************************** Log_name: binlog.000006 Pos: 4 Event_type: Format_desc Server_id: 101 End_log_pos: 245 Info: Server ver: 5.5.56-MariaDB, Binlog ver: 4
二進制日誌的滾動：
自動滾動：由MySQL自行控制的日誌滾動；
通過服務器參數來控制的單個二進制日誌文件的大小上限；
MariaDB [(none)]> show global variables like 'max_binlog_size'; +-----------------+------------+ | Variable_name | Value | +-----------------+------------+ | max_binlog_size | 1073741824 | +-----------------+------------+
注意：因爲二進制日誌是在事務提交之後纔會保存且每個事務都必須存放於一個二進制日誌文件中，所以一些大事務的提交可能使得二進制日誌文件的大小超過這個上限的值；
手動滾動：由用戶控制的日誌滾動；
1.重啓MySQL服務；
2.在MySQL客戶端的交互式模式中執行"FLUSH LOGS"語句；
其他的一些與二進制日誌有關的重要參數信息；
sql_log_bin = { ON | OFF }
指定是否啓用二進制日誌功能；只有在log_bin參數的值爲ON時有效；
sync_binlog = N
sync_binlog=0：異步更新；
MySQL不會選擇同步緩存的信息到磁盤文件，緩存中的二進制日誌何時刷寫到磁盤由文件系統決定；該參數設定時MySQL的性能很好，但並不能很好的保證數據的一致性和持久性；
sync_binlog=N；每寫入N次二進制日誌的事件(不是事務的數量)，mysql會執行一次磁盤同步指令fdatasync()將緩存中的二進制日誌刷寫到磁盤日誌文件中；爲了保證數據集的持久性，通常會使用sync_binlog=1，尤其是在MySQL/MariaDB的主從複製架構之中；
二進制日誌的大致內容格式：
中繼日誌：
其內容就是二進制日誌的內容；
在主從架構的MySQL集羣服務中，從服務器會從主服務器複製二進制日誌到本地，將其保存在中繼日誌中；
二進制日誌的格式是二進制格式，中繼日誌的文件格式爲純文本格式；
與中繼日誌有關的相關參數：
relay_log = { ON | OFF | PATH }
中繼日誌功能開關，定義了中繼日誌存放的路徑和文件名稱；如果此參數值爲空，則默認會將中繼日誌放置於數據目錄中，文件名默認爲：HOSTNAME-relay-bin.xxxxxx;
注意：通常需要使用中繼日誌時，直接定義出文件的路徑，而不使用默認值；以防止在主機名被更改之後，無法定位日誌文件的位置；
relay_log_recovery = { ON | OFF }
當從服務從宕機狀態恢復後，如果中繼日誌損壞，導致一部分日誌中的語句無法被重放或者全部不能被重放，此時是否自動放棄所有未執行的中繼日誌的內容，並且從主服務器重新獲取二進制日誌的功能開關；建議開啓；
事務日誌：
在MySQL或MariaDB系統中，一般就是指InnoDB的事務日誌，包含兩種日誌；
redo log
提供數據重做功能，實現前滾操作；
通常是物理日誌；記錄的是數據頁的物理修改，而不是針對於某一行或某幾行的修改結果；
如果使用redo log恢復數據，能恢復到最後一次提交事務後的位置；
undo log
提供數據恢復功能，實現回滾操作：
提供了恢復操作及MVCC功能；undo log中存放的內容是對應的行在被修改之前的內容，或者與修改數據相反的SQL語句；
undo log一般是邏輯日誌，根據每行中的數據修改來進行記錄，通常存放於邏輯表空間中；
注意：undo log的執行過程並是不會redo log 的逆過程，實際上着兩種日誌都是用來實現恢復功能的日誌；
redo log的第一部分是否能夠持久存儲，MySQL中通過innodb_flush_log_at_trx_commit服務器參數來進行控制；
innodb_flsuh_log_at_trx_commmit = N 默認是2；
如果該參數取值爲1，事務每次提交都會將日誌緩存中的日誌寫入操作系統的緩衝區並立即調用fsync()刷寫到"log file on disk"中，這種日誌刷寫方式即使系統直接崩潰也會丟失任何數據，數據的持久性也可以得到保證；但是每次提交事務都需要寫入磁盤，IO性能非常差；
如果該參數爲0，事務提交後，不會將事務日誌緩存緩衝區中的日誌寫入操作系統的緩衝區，每秒鐘提交給操作系統緩衝區一次並調用fsync()刷寫到"log file on disk"中；如果系統崩潰，會丟失一秒內的所有數據；
如果該參數值爲2，每次提交事務都直接寫入操作系統的緩存，然後由操作系統每秒調用fsync()函數將操作系統緩衝區中的日誌內容寫入到"log file on disk"中；如果MySQL服務崩潰，不會丟失數據；但如果操作系統崩潰，會丟失一秒內的所有數據；
MariaDB [(none)]> show global variables like 'innodb_flush_log_at_trx_commit'; +--------------------------------+-------+ | Variable_name | Value | +--------------------------------+-------+ | innodb_flush_log_at_trx_commit | 2 | +--------------------------------+-------+
undo log的作用：
1.提供回滾功能；
2.多版本並行控制(MVCC)
在數據被修改時，InnoDB不僅記錄的redo log，還記錄了undo log；
因此可以在開啓事務之後的執行操作過程中，因爲某些操作失敗或因爲某些操作不合理，而藉助於undo log進行回滾；
undo log與redo log形式上不同，屬於邏輯日誌。存放於表空間中；
undo log默認存放在共享表空間中，如果啓用了innodb_file_per_table服務器參數，則意味着每個表的獨立表空間中均會保存與該表相關的undo log；
MariaDB [(none)]> show global variables like 'innodb_file_per_table'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | ON | +-----------------------+-------+
