MySQL日誌

在 MySQL 中有 4 種不一樣的日誌, 分別爲錯誤日誌, 查詢日誌和慢查詢日誌, 二進制日誌. 默認狀況下, 爲儘可能減小 IO 損耗, 系統只打開錯誤日誌. 若須要複製, 就必需要打開二進制日誌.php

錯誤日誌

錯誤日誌在 MySQL 數據庫中很重要, 它記錄着 MySQL 啓動和中止, 以及服務器在運行過程當中發生的任何錯誤的相關信息.mysql

配置
若是配置文件 my.cnf 沒有指定 log_eror, 則錯問日誌默認文件名爲 hostname.err, 存放於 datadir 目錄中.sql

mysql> SHOW VARIABLES LIKE 'log_error';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_error     |       |
+---------------+-------+
1 row in set (0.00 sec)

將 log-error 配置到 my.cnf 文件中數據庫

[mysqld]
log_error=/usr/local/mysql/var/mysql-error.err

查詢日誌

查詢日誌記錄了全部操做的語句. 因爲它記錄數據庫全部操做, 對於訪問頻繁的系統, 此種日誌會形成性能影響, 因此通常不會將其打開.緩存

配置
若是配置文件 my.cnf 有打開log選項, 但未指定具體文件名和路徑, 則其默認文件名爲 hostname.log, 存放於 datadir 目錄中.安全

默認時查詢日誌變量值服務器

mysql> SHOW VARIABLES LIKE 'log';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log           | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

若是有須要使用到查詢日誌, 將 log 配置到 my.cnf 文件中工具

[mysqld]
log=/usr/local/mysql/var/mysql_query.log

查詢日誌是純文本格式, 可以使用文本讀取工具直接打開查看.性能

慢查詢日誌

慢查詢日誌是記錄執行時間超過參數 slow_launch_time(unit: s, v5.1 默認 2s v5.0.* 是 long_query_time)所設定值的 SQL 語句日誌. 它有助於發現性能有問題的 SQL.ui

打開慢日誌對系統性能的總體影響沒有 binlog 那麼大, 但系統須要計算每一條查詢的執行時間, 全部, 在 CPU 方面仍是有損耗的. 若是 CPU 資源不夠, 可在大部分時候關閉這個, 只需間斷性的打開來定位可能存在的慢查詢.

配置
若是配置文件 my.cnf 有打開log_slow_queries選項, 但未指定具體文件名和路徑, 則其默認文件名爲 hostname-slow.log, 存放於 datadir 目錄中.

默認狀況下慢日誌查詢變量(v5.1):

mysql> SHOW VARIABLES LIKE '%slow%';
+---------------------+----------------------------------+
| Variable_name       | Value                            |
+---------------------+----------------------------------+
| log_slow_queries    | OFF                              |
| slow_launch_time    | 2                                |
| slow_query_log      | OFF                              |
| slow_query_log_file | /usr/local/mysql/var/db-slow.log |
+---------------------+----------------------------------+
4 rows in set (0.00 sec)

若是有須要使用到慢查詢日誌, 將 log_slow_queries 配置到 my.cnf 文件中

[mysqld]
log_slow_queries=/usr/local/mysql/var/mysql_slow_query.log

也能夠在啓動 MySQL 服務時, 加上 –log_slow_queries=filename.log

若須要進一步縮短慢查詢時間限制, 可以使用 Percona 提供的 microslow-patch(msl Patch). 它不只能將時間減少到毫秒級別, 還能經過一些特定的規則來過濾記錄的SQL, 如只記錄某個表的慢查詢.

查看慢日誌

二進制日誌

二進制日誌記錄了全部的 DDL 和 DML 的語句, 但不包括查詢語句, 語句以事件方式保存, 此日誌對發生災難時數據恢復極爲重要. MySQL 複製時, 必須將其打開.

啓用配置

[mysqld]
log-bin=/usr/local/mysql/var/mysql-bin

mysql-bin 爲日誌文件名,MySQL 在文件名後添加數字索引,因此該文件最後的形式相似於 mysql-bin.000001.若是在指定文件名時相似於 myql-bin.log, .log 會自動忽略. 該日誌沒有指定相對路徑時,默認存放於 datadir 目錄中.

以下狀況時,二進制日誌會更換到新的文件:

服務器重啓
服務器被更新
日誌達到最大日誌長度 max_binlog_size
在 MySQL 命令終端 FLUSH LOGS
打開配置時各變量值(v5.1)

mysql> SHOW VARIABLES LIKE '%bin%';
+-----------------------------------------+----------------------+
| Variable_name                           | Value                |
+-----------------------------------------+----------------------+
| binlog_cache_size                       | 32768                |
| binlog_direct_non_transactional_updates | OFF                  |
| binlog_format                           | STATEMENT            |
| binlog_stmt_cache_size                  | 32768                |
| innodb_locks_unsafe_for_binlog          | OFF                  |
| log_bin                                 | ON                   |
| log_bin_trust_function_creators         | OFF                  |
| max_binlog_cache_size                   | 18446744073709547520 |
| max_binlog_size                         | 1073741824           |
| max_binlog_stmt_cache_size              | 18446744073709547520 |
| sql_log_bin                             | ON                   |
| sync_binlog                             | 0                    |
+-----------------------------------------+----------------------+
12 rows in set (0.00 sec)

部分變量值說明

binlog_cache_size 事務過程當中容納二進制日誌 SQL 語句的緩存大小. 二進制日誌緩存是服務器支持事務存儲引擎, 且服務器啓用了二進制日誌(log_bin)的前提下爲每一個客戶端分配的內存, 注意是給每一個客戶端能夠分配設置大小的 binlog cache 空間. 若是系統中會出現多語句的事務, 增長該值的大小, 以獲得更好的性能.
max_binlog_cache_size 和binlog_cache_size對應, 它表明的是 binlog 能使用的最大 cache 值大小. 當不夠大時, 系統可能會報「Multi_statement transaction required more than ‘max_binlog_cache_size’ bytes of storage」.
max_binlog_size binlog 最大值, 通常設置爲 512KB 或 1GB, 但不能超過 1GB.
sync_binlog影響到 binlog 對 MySQL 所帶來的性能消耗, 還影響到數據的完整性, 參數說明以下:
sync_binlog=0 事務提交後, 僅僅是將 binlog_cache 中的數據寫入到 binlog 文件中, 但不執行 fsync 之類的磁盤操做指令通知文件系統將緩存刷新到磁盤, 而讓文件系統自行決定何時來同步. sync_binlog=N 進行 N 次事務提交後, 系統將執行一次 fsync 之類的磁盤同步指令, 通知文件系統將 binlog 文件的緩存刷新到磁盤. 默認是 sync_binlog=0, 性能是最好, 可是風險是最大, 由於一旦系統 crash, 文件系統緩存中的 binlog 將都會丟失.設置爲 1 時, 最安全但性能損耗最大, 當系統 crash 時, 最多隻會丟失 binlog_cache 中未完成的一個事務, 對實際數據沒有任何的影響.sync_binlog=0 性能 有多是 sync_binlog=1 時的5倍.
記錄內容配置
binlog_do_db=example1,example2 設定那些 db 須要記錄binlog
binlog_ignore_db=test1,test2 設定那些 db不要記錄 binlog

注:
若是在操做數據庫以前,不使用use $dbname , 那麼全部的SQL都不會記錄, 若是使用了use $dbname,那麼判斷規則取決於這裏的$dbname,而不是 SQL 中操做的庫.

若是配置文件中沒有配置這兩個選項,則該主機上全部庫的 DML 和 DLL 語句都會被記錄。

相關文章
相關標籤/搜索