MySQL日誌管理
第1章 mysql日誌類型
1.1 mysql日誌類型簡介:
1.1 錯誤日誌:
1.1.1 作用:
記錄mysql數據庫的一般狀態信息及報錯信息,是對數據庫報錯處理常用的日誌
1.1.2 配置方法:
[mysqld] log-error=/var/log/mysql.log
1.1.3 配置查看方式:
mysql> show variables like '%log_error%'; +---------------------+--------------------+ | Variable_name | Value | +---------------------+--------------------+ | binlog_error_action | IGNORE_ERROR | | log_error | /var/log/mysql.log | +---------------------+--------------------+
1.2 常規查詢日誌:
1.2.1 作用:
記錄mysql所有執行成功的sql語句信息,可以做審計使用,但是很少開啟此項
因為執行過的成功的語句都會記錄,會浪費磁盤io
1.2.2 配置方法:
[mysqld] general_log=1 general_log_file=/ application/mysql/data/db01.log
1.2.3 配置查看方法:
mysql> show variables like '%general%'; +------------------+----------------------------------+ | Variable_name | Value | +------------------+----------------------------------+ | general_log | OFF | | general_log_file | /application/mysql/data/db01.log | +------------------+----------------------------------+
第2章 二進制日誌:
2.1 二進制日誌基本配置
2.1.1 作用:
1. 提供備份功能
2. 進行主從復制
3. 基於時間點的任意恢復
4. 記錄在sql層已經執行完成的語句,如果是事務,則記錄已經完成的事務
2.1.2 配置文件開啟方法:
[mysqld] log_bin=/data/mysql/mysql-bin 默認就是開啟狀態,這樣設置是為了指定存放路徑
2.1.3 查看二進制文件的類型:
[root@db01 mysql]# file mysql-bin.* mysql-bin.000001: MySQL replication log mysql-bin.index: ASCII text
2.1.4 查看二進制日誌配置:
mysql> show variables like '%log_bin%'; +---------------------------------+-----------------------------+ | Variable_name | Value | +---------------------------------+-----------------------------+ | log_bin | ON | | log_bin_basename | /data/mysql/mysql-bin | | log_bin_index | /data/mysql/mysql-bin.index | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | | sql_log_bin | ON | +---------------------------------+-----------------------------+
2.1.5 二進制日誌記錄格式:
statement:
SBR,語句模式記錄二進制日誌
SBR在數據恢復角度來講不夠好,如果操作時帶有函數的操作,會導致恢復備份數據時,改變數據
row:
RBR,行模式記錄二進制日誌
mixed:
MBR,混合模式記錄二進制日誌
2.1.5.1 配置文件修改二進制日誌格式:
[mysqld] binlog_format=row
2.1.5.2 命令行修改二進制日誌格式方法:
mysql> set global binlog_format='row'; mysql> set global binlog_format='mixed'; mysql> set global binlog_format='statement';
2.1.5.3 查看當前二進制文件定義的格式:
mysql> show variables like '%format%'; +--------------------------+-------------------+ | Variable_name | Value | +--------------------------+-------------------+ | binlog_format | ROW | | date_format | %Y-%m-%d | | datetime_format | %Y-%m-%d %H:%i:%s | | default_week_format | 0 | | innodb_file_format | Antelope | | innodb_file_format_check | ON | | innodb_file_format_max | Antelope | | time_format | %H:%i:%s | +--------------------------+-------------------+
2.2 二進制文件的操作:
2.2.1 操作系統層面查看:
[root@db01 mysql]# pwd /data/mysql [root@db01 mysql]# ll total 76 -rw-rw---- 1 mysql mysql 143 Apr 9 15:24 mysql-bin.000001 -rw-rw---- 1 mysql mysql 657 Apr 9 17:02 mysql-bin.000002
2.2.2 刷新日誌:
mysql> flush logs; Query OK, 0 rows affected (0.32 sec)
2.2.3 查看當前使用的二進制日誌文件:
mysql> show master status; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000012 | 120 | | | | +------------------+----------+--------------+------------------+-------------------+
2.2.4 查看所有的二進制日誌文件:
mysql> show binary logs; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000001 | 143 | | mysql-bin.000002 | 657 | | mysql-bin.000003 | 143 | | mysql-bin.000004 | 143 | | mysql-bin.000005 | 143 | +------------------+-----------+ 5 rows in set (0.00 sec)
名次說明:
1. 事件 events
a) 命令發生的最小單元,一個事務,是由多個事件組成
2. position
a) 每個事件在整個二進制文件中對應的位置號就是position號
2.2.5 導出二進制日誌文件中的信息:
mysqlbinlog mysql-bin.000012 >/tmp/bin.txt
2.2.6 binlog日誌的查看方式:
1. 查看binlog日誌原始信息:
mysqlbinlog mysql-bin.000012 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #180409 21:10:05 server id 3306 end_log_pos 120 CRC32 0xf967602d Start: binlog v 4, server v 5.6.36-log created 180409 21:10:05 # Warning: this binlog is either in use or was not closed properly. BINLOG ' LWbLWg/qDAAAdAAAAHgAAAABAAQANS42LjM2LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAS1g Z/k= '/*!*/; DELIMITER ; # End of log file
2. 在row(行模式)下,翻譯成sql語句
mysqlbinlog --base64-output=decode-rows -v /data/mysql/mysql-bin.000001 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #180409 13:52:02 server id 3306 end_log_pos 120 CRC32 0x1e347f1c Start: binlog v 4, server v 5.6.36-log created 180409 13:52:02 at startup # Warning: this binlog is either in use or was not closed properly. ROLLBACK/*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
3. 查看binlog事件:
mysql> show binlog events in 'mysql-bin.000010'; +------------------+-----+-------------+-----------+-------------+---------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+-------------+-----------+-------------+---------------------------------------+ | mysql-bin.000010 | 4 | Format_desc | 3306 | 120 | Server ver: 5.6.36-log, Binlog ver: 4 | | mysql-bin.000010 | 120 | Query | 3306 | 193 | BEGIN | | mysql-bin.000010 | 193 | Table_map | 3306 | 239 | table_id: 70 (jiang.t1) | | mysql-bin.000010 | 239 | Write_rows | 3306 | 289 | table_id: 70 flags: STMT_END_F | | mysql-bin.000010 | 289 | Xid | 3306 | 320 | COMMIT /* xid=11 */ | | mysql-bin.000010 | 320 | Query | 3306 | 393 | BEGIN | | mysql-bin.000010 | 393 | Table_map | 3306 | 439 | table_id: 71 (jiang.t1) | | mysql-bin.000010 | 439 | Write_rows | 3306 | 484 | table_id: 71 flags: STMT_END_F | | mysql-bin.000010 | 484 | Xid | 3306 | 515 | COMMIT /* xid=35 */ | | mysql-bin.000010 | 515 | Stop | 3306 | 538 | | +------------------+-----+-------------+-----------+-------------+---------------------------------------+
2.2.7 刪除二進制日誌文件:
重置二進制日誌,從1開始計數:
mysql> reset master; Query OK, 0 rows affected (0.35 sec) [root@db01 mysql]# ll total 24 -rw-rw---- 1 mysql mysql 120 Apr 9 13:52 mysql-bin.000001 -rw-rw---- 1 mysql mysql 29 Apr 9 13:52 mysql-bin.index -rw-rw---- 1 mysql mysql 16360 Apr 9 13:52 slow.log
根據存在時間刪除:
mysql> set global_logs_days=7; mysql> purge binary logs before now() - interval 3 day;
2.2.8 二進制日誌在何時滾動:
1. 重啟mysql服務
2. mysqldump –F 參數
3. 命令行執行flush
2.3 如何截取你需要的事務?
1. show binary logs; show master status;
2. show binlog events in ‘日誌名’;從後往前看,找到誤操作事務,判斷事務開始和結束的position
3. 把誤操作的剔除掉,留下正常操作到2個sql文件中
4. 先在測試庫恢復,把誤操作數據導出,然後在生產庫恢復
2.3.1 上述方法存在的缺點:
1. 恢復時間較長
2. 對生產數據有一定的影響,有可能會出現冗余數據
2.3.2 較好的解決辦法:
1. flashback閃回功能
2. 通過備份,延時從庫
2.3.3 mysqlbinlog命令截取二進制日誌常用參數:
參數 | 參數說明 |
--start-datetime | 從二進制日誌中讀取指定等於時間戳或者晚於本地計算機的時間 |
--stop-datetime | 從二進制日誌中讀取指定小於時間戳或者等於本地計算機的時間取值和上述一樣 |
--start-position | 從二進制日誌中讀取指定position 事件位置作為開始。 |
--stop-position | 從二進制日誌中讀取指定position 事件位置作為事件截至 |
第3章 慢日誌管理:
3.1 作用:
1. slow-log 記錄所有條件內的慢的sql語句
2. 優化的一種工具日誌,可以幫助我們定位問題
3.2 開啟慢日誌
vim /etc/my.cnf slow_query_log 指定是否開啟慢日誌 slow_query_log_file=/data/mysql/slow.log 指定慢日誌位置,可以為空,系統默認為host_name-slow.log long_query_time=0.01 設定閾值,超出設定值的sql語句會被記錄到慢日誌中,缺省為10s log_queries_not_using_indexes 不使用索引的sql語句是否記錄到慢日誌
3.3 查看慢日誌相關配置:
mysql> show variables like '%slow%'; +---------------------------+----------------------+ | Variable_name | Value | +---------------------------+----------------------+ | log_slow_admin_statements | OFF | | log_slow_slave_statements | OFF | | slow_launch_time | 2 | | slow_query_log | ON | | slow_query_log_file | /data/mysql/slow.log | +---------------------------+----------------------+
3.4 判斷慢語句的條件:
1. 按照時間長短
2. 不走索引的慢查詢日誌是否記錄到索引
3. 查詢檢查返回少於該參數指定行的sql不被記錄到慢查詢日誌
3.4.1 分析慢日誌的角度:
1. 按照執行時間
2. 按照執行次數
3.4.2 例子:
mysqldumpslow -s c -t 10 /data/mysql/slow.log Reading mysql slow query log from /data/mysql/slow.log Count: 19 Time=0.02s (0s) Lock=0.00s (0s) Rows=0.0 (0), root[root]@localhost INSERT INTO `city` VALUES (N,'S','S','S',N) Count: 11 Time=0.00s (0s) Lock=0.00s (0s) Rows=4.6 (51), root[root]@localhost select * from t1
3.5 mysqldumpslow 命令的參數
數 | 說明 |
-s | 是表示按照何種方式排序，c、t、l、r分別是按照記錄次數、時間、查詢 時間、返回的記錄數來排序，ac、at、al、ar，表示相應的倒敘； |
-t | 是top n的意思，即為返回前面多少條的數據； |
-g | 後邊可以寫一個正則匹配模式，大小寫不敏感的； |
3.6 怎麽保證binlog和redolog已提交事務的一致性:
在沒有開啟binlog的時候,執行commit,就認為redo日誌持久化到磁盤中,即落地成功,commit命令就成功
3.6.1 查看寫binlog的參數:
sync_binlog 確保每個提交的事務都寫到binlog中
mysql> show variables like '%sync_binlog%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sync_binlog | 0 | #控制binlog commit階段 +---------------+-------+ 1 row in set (0.00 sec)
參數意義說明:
sync_binlog=1
默認值是0,像操作系統刷新其他文件的機制一樣,mysql不會同步到磁盤中去而是依賴操作系統來刷新binary log
當sync_binlog=N(N>0),mysql在沒寫N次二進制日誌binarylog時,會使用fdatasync()函數將它的寫二進制日誌binary log同步到磁盤中去
如果啟動了autocommit 那麽每一個語句statement就會有一次寫操作,否則每個事務對應一個寫操作
企業案例:
業務人員反映,每天10-11點時間段,業務特別慢,其他時間都沒有問題
解決思路:
1. 排除系統層面問題,確認是數據庫方面問題
2. 慢日誌自帶時間戳,可以根據時間段,利用awk截取出日誌中慢的sql語句
3. 使用pt-分析slowlog,找到top sql
4. 使用explain逐個分析top sql,最終發現,在排序條件上,未建立索引
5. 對問題SQL進行優化處理
結果:
經過處理,原SQL
MySQL日誌管理