MySQL 日志文件與相關參數


1 、參數文件及mysql參數

查看mysql 的 my.cnf 配置文件位置命令:>./bin/mysql --help | grep my.cnf  

查看mysql 的參數設置命令: mysql >  show variables  --顯示所有參數; // show variables like 'log_error%' 顯示某匹配參數

mysql > select @@session.read_buffer_size; 查看當前session的read_buffer_size

mysql > select @@global.read_buffer_size; 查看全局的read_buffer_size
mysql > set  @@session.read_buffer_size=1024000; 設置當前session的read_buffer_size

mysql > set  @@session.read_buffer_size=1024000; 設置當前session的read_buffer_size

2、日志文件 

my.cnf 的啟動選項

======== 數據庫日志選項(值為[file_name]) ========

--log 常規日志文件

--log_bin 二進制變更日志文件

--log-bin-index 二進制變更日志文件索引文件

--log-update 變更日志文件

--log-slow-queries 慢查詢日志文件

--log-isam ISAM/MyISAM日志文件

--log-long-format  設置慢查詢日志和變更日志的格式


======== 數據表日志選項( 值為[dir_name])========

 --bdb-logdir 存放BDB日志文件的位置

--innodb-log_arch_dir 存放InnoDB日志文件的歸檔位置

--innodb_log_group_home_dir  存放InnoDB日志文件的位置

 

1) 錯誤日志 (my.cnf 配置文件中使用 log-error [=file_name] 設置,在SQL中使用  mysql> show variables like 'log_error%';  查看位置)
  錯誤日志文件包含了當mysqld啟動和停止時,以及服務器在運行過程中發生任何嚴重錯誤時的相關信息。
如果mysqld莫名其妙地死掉並且mysqld_safe需要重新啟動它,mysqld_safe在錯誤日志中寫入一條restarted mysqld消息。如果mysqld注意到需要自 動檢查或着修復一個表,則錯誤日志中寫入一條消息。
在一些操作系統中,如果mysqld死掉,錯誤日志包含堆棧跟蹤信息。跟蹤信息可以用來確定mysqld死掉的地方(參見“使用堆棧跟蹤”)。
如果在啟動參數文件中沒有給定log-error 的值,mysqld使用錯誤日志名host_name.err 並在數據目錄中寫入日志文件。如果你執行FLUSH LOGS,錯 誤日志用-old重新命名后綴並且mysqld創建一個新的空日志文件。(如果未給出--log-error選項,則不會重新命名)。

如果不指定--log-error,或者(在Windows中)如果你使用--console選項,錯誤被寫入標准錯誤輸出stderr。通常標准輸出為你的終端。在Windows中, 如果未給出--console選項,錯誤輸出總是寫入.err文件。

2) 查詢日志 (my.cnf 配置文件中使用 log[=file_name] 設置,或者在mysql啟動時使用 -l file_name啟動參數設置,默認值為 host_name.log) 
查詢日志是記錄建立的客戶端連接和執行的語句, mysql按照它接收的順序記語句到log文件中,這樣你就可以查看 mysql 內部發生了什么;查詢日志與
更新日志和二進制日志不同, 它們在查詢執行后,但是任何一個鎖釋放之前記錄日志(它還包括所有語句,而二進制文件不包含只查詢語句)
 服務器重新啟動和日志刷新不會產生新的一般查詢日志文件(盡管刷新關閉並重新打開一般查詢日志文件)。
在Unix中,你可以通過下面的命令重新命名文件並創建一個新文件:簡單的mv、rm、cp 命令 或者使用 mysqladmin flush-logs。
在Windows中,你只能通過先停止服務器, 把日志文件重命名再啟動服務器來創建新的日志文件。

3)二進制日志 (my.cnf配件文件中使用 log-bin [=file_name]設置,默認值為 -bin_hostname)

二進制日志以一種更有效的格式,並且是事務安全的方式包含更新日志中可用的所有信息(5.1后的版本中不再使用 更新日志)
二進制日志包含了所有更新了數據或者已經潛在更新了數據(例如,沒有匹配任何行的一個 DELETE或UPDATE)的所有語句。語句以“事件”的形式保存, 它描述數據更改。   二進制日志還包含關於每個更新數據庫的語句的執行時間信息,但它不包含沒有修改任何數據的語句。
>二進制日志的主要目的是在恢復使能夠最大可能地更新數據庫,因為二進制日志包含備份后進行的所有更新;
  >二進制日志還用於在主復制服務器上記錄所有將發送給從服務器的語句
>二進制默認寫入至數據目錄,以-bin<hostname>.00001  mysqld自動在每個日志后面添加一個數據擴展名   ,當前的日志大小達到 max_binlog_size 時自動創建新的二進制日志,一個事務只能寫入 同一個日志文件中。
>mysqld創建一個二進制日志索引文件,包含所有使用的二進制日志文件的文件名,使用戶能知道 哪個不同的二進制日志文件。默認情況下二進制日志索 文件與二進制日志文件的文件名相同, 擴展名為".index"。
> 你可以用--log-bin-index[=file_name]選項更改二進制日志索引文件的文件名;當mysqld在運行時,不應手動編輯該文件;如果這樣做將會使mysqld變 混亂。 可以用RESET MASTER語句刪除所有二進制日志文件,或用PURGE MASTER LOGS只刪除部分二進制文件。  
  二進制日志格式有一些已知限制,會影響從備份恢復。參見“復制特性和已知問題”。
>保存程序和觸發器的二進制日志的描述參,“存儲子程序和觸發程序的二進制日志功能”。

  可以使用下面的mysqld選項來影響記錄到二進制日志知的內容。又見選項后面的討論。

--binlog-do-db=db_name 

告訴主服務器,如果當前的數據庫(即USE選定的數據庫)是db_name,應將更新記錄到二進制日志中。其它所有沒有明顯指定的數據庫 被忽略。如果使用該選項,你應確保只對當前的數據庫進行更新。
對於CREATE DATABASE、ALTER DATABASE和DROP DATABASE語句,有一個例外,即通過操作的數據庫來決定是否應記錄語句,而不是用當前的數據庫。
--binlog-ignore-db=db_name
告訴主服務器,如果當前的數據庫(即USE選定的數據庫)是db_name,不應將更新保存到二進制日志中。如果你使用該選項,你應確保只對當前的數據庫進行更新。
類似於--binlog-do-db,對於CREATE DATABASE、ALTER DATABASE和DROP DATABASE語句,有一個例外,即通過操作的數據庫來決定是否應記錄語句,而不是用當前的數據庫。
要想記錄或忽視多個數據庫,使用多個選項,為每個數據庫指定相應的選項。
服務器根據下面的規則對選項進行評估,以便將更新記錄到二進制日志中或忽視。請注意對於CREATE/ALTER/DROP DATABASE語句有一個例外。在這些情況下,根據以下規則,所創建、修改或刪除的數據庫將代替當前的數據庫。
1. 是否有binlog-do-db或binlog-ignore-db規則?
· 沒有:將語句寫入二進制日志並退出。
· 有:執行下一步。
2. 有一些規則(binlog-do-db或binlog-ignore-db或二者都有)。當前有一個數據庫(USE是否選擇了數據庫?)?
· 沒有:不要寫入語句,並退出。
· 有:執行下一步。
3. 有當前的數據庫。是否有binlog-do-db規則?
· 有:當前的數據庫是否匹配binlog-do-db規則?
o 有:寫入語句並退出。
o 沒有:不要寫入語句,退出。
· No:執行下一步。
4. 有一些binlog-ignore-db規則。當前的數據庫是否匹配binlog-ignore-db規則?
· 有:不要寫入語句,並退出。
· 沒有:寫入查詢並退出。
例如,只用binlog-do-db=sales運行的服務器不將當前數據庫不為sales的語句寫入二進制日志(換句話說,binlog-do-db有時可以表示“忽視其它數據庫”)。

如果你正進行復制,應確保沒有從服務器在使用舊的二進制日志文件,方可刪除它們。一種方法是每天一次執行mysqladmin flush-logs並刪除三天前的所有日志。可以手動刪除,或最好使用PURGE MASTER LOGS(參見“用於控制主服務器的SQL語句”),該語句還會安全地更新二進制日志索引文件(可以采用日期參數)。 

具有SUPER權限的客戶端可以通過SET SQL_LOG_BIN=0語句禁止將自己的語句記入二進制記錄。參見13.5.3節,“SET語法”。
你可以用mysqlbinlog實用工具檢查二進制日志文件。如果你想要重新處理日志止的語句,這很有用。例如,可以從二進制日志更新MySQL服務器,方法如下:
shell> mysqlbinlog log-file | mysql -h server_name
關於mysqlbinlog實用工具的詳細信息以及如何使用它,參見“mysqlbinlog:用於處理二進制日志文件的實用工具”。
如果你正使用事務,必須使用MySQL二進制日志進行備份,而不能使用舊的更新日志。
查詢結束后、鎖定被釋放前或提交完成后則立即記入二進制日志。這樣可以確保按執行順序記入日志。
對非事務表的更新執行完畢后立即保存到二進制日志中。對於事務表,例如BDB或InnoDB表,所有更改表的更新(UPDATE、DELETE或INSERT) 被緩存起來,直到服務器接收到COMMIT語句。在該點,執行完COMMIT之前,mysqld將整個事務寫入二進制日志。當處理事務的線程啟動時,它為緩沖查詢分配binlog_cache_size大小的內存。如果語句大於該值,線程則打開臨時文件來保存事務。線程結束后臨時文件被刪除。
Binlog_cache_use狀態變量顯示了使用該緩沖區(也可能是臨時文件)保存語句的事務的數量。Binlog_cache_disk_use狀態變量顯示了這些事務中實際上有多少必須使用臨時文件。這兩個變量可以用於將binlog_cache_size調節到足夠大的值,以避免使用臨時文件。
max_binlog_cache_size(默認4GB)可以用來限制用來緩存多語句事務的緩沖區總大小。如果某個事務大於該值,將會失敗並 回滾。
如果你正使用更新日志或二進制日志,當使用CREATE ... SELECT or INSERT ... SELECT時,並行插入被轉換為普通插入。這樣通過在備份時使用日志可以確保重新創建表的備份。
請注意MySQL 5.1值的二進制日志格式與以前版本的MySQL不同,因為復制改進了。參見“不同MySQL版本之間的復制兼容性”。
默認情況下,並不是每次寫入時都將二進制日志與硬盤同步。因此如果操作系統或機器(不僅僅是MySQL服務器)崩潰,有可能二進制日志中最后的語句丟失了。要想防止這種情況,你可以使用sync_binlog全局變量(1是最安全的值,但也是最慢的),使二進制日志在每N次二進制日志寫入后與硬盤同步。參見5.3.3節,“服務器系統變量”。即使sync_binlog設置為1,出現崩潰時,也有可能表內容和二進制日志內容之間存在不一致性。例如,如果使用InnoDB表,MySQL服務器處理COMMIT語句,它將整個事務寫入二進制日志並將事務提交到InnoDB中。如果在兩次操作之間出現崩潰,重啟時,事務被InnoDB回滾,但仍然存在二進制日志中。可以用--innodb-safe-binlog選項解決該問題,可以增加InnoDB表內容和二進制日志之間的一致性。(注釋:在MySQL 5.1中不需要--innodb-safe-binlog;由於引入了XA事務支持,該選項作廢了)。
該選項可以提供更大程度的安全,還應對MySQL服務器進行配置,使每個事務的二進制日志(sync_binlog =1)和(默認情況為真)InnoDB日志與硬盤同步。該選項的效果是崩潰后重啟時,在滾回事務后,MySQL服務器從二進制日志剪切 回滾的InnoDB事務。這樣可以確保二進制日志反饋InnoDB表的確切數據等,並使從服務器保持與主服務器保持同步(不接收 回滾的語句)。
請注意即使MySQL服務器更新其它存儲引擎而不是InnoDB,也可以使用--innodb-safe-binlog。在InnoDB崩潰恢復時,只從二進制日志中刪除影響InnoDB表的語句/事務。如果崩潰恢復時MySQL服務器發現二進制日志變短了(即至少缺少一個成功提交的InnoDB事務),如果sync_binlog =1並且硬盤/文件系統的確能根據需要進行同步(有些不需要)則不會發生,則輸出錯誤消息 ("二進制日志<名>比期望的要小")。在這種情況下,二進制日志不准確,復制應從主服務器的數據快照開始。

寫入二進制日志文件和二進制日志索引文件的方法與寫入MyISAM表相同。參見A.4.3節,“MySQL處理磁盤滿的方式”。

 

4) 慢速查詢日志 用--log-slow-queries[=file_name]選項啟動時,mysqld寫一個包含所有執行時間超過long_query_time秒的SQL語句的日志文件。獲得初使表鎖定的時間不算作執行時間。如果沒有給出file_name值, 默認未主機名,后綴為-slow.log。如果給出了文件名,但不是絕對路徑名,文件則寫入數據目錄。
語句執行完並且所有鎖釋放后記入慢查詢日志。記錄順序可以與執行順序不相同。

>慢查詢日志可以用來找到執行時間長的查詢,可以用於優化。但是,檢查又長又慢的查詢日志會很困難。要想容易些,你可以使用mysqldumpslow命令獲得日志中顯示的查詢摘要來處理慢查詢日志。 

>在MySQL 5.1的慢查詢日志中,不使用索引的慢查詢同使用索引的查詢一樣記錄。要想防止不使用索引的慢查詢記入慢查詢日志,使用--log-short-format選項。參見,“mysqld命令行選項”。
>在MySQL 5.1中,通過--log-slow-admin-statements服務器選項,你可以請求將慢管理語句,例如OPTIMIZE TABLE、ANALYZE TABLE和 ALTER TABLE寫入慢查詢日志。
>用查詢緩存處理的查詢不加到慢查詢日志中,因為表有零行或一行而不能從索引中受益的查詢也不寫入慢查詢日志。

 

3、 日志文件維護

MySQL服務器可以創建各種不同的日志文件,從而可以很容易地看見所進行的操作。參見“MySQL日志文件”。但是,你必須定期清理這些文件,確保日志不會占用太多的硬盤空間。
當啟用日志使用MySQL時,你可能想要不時地備份並刪除舊的日志文件,並告訴MySQL開始記入新文件。參見“數據庫備份”。
在 Linux (Redhat)的安裝上,你可為此使用mysql-log-rotate腳本。如果你從RPM分發安裝MySQL,腳本應該自動被安裝了。
在其它系統上,你必須自己安裝短腳本,你可從cron等入手處理日志文件。
你可以通過mysqladmin flush-logs或SQL語句FLUSH LOGS來強制MySQL開始使用新的日志文件。
日志清空操作做下列事情:
如果使用標准日志(--log)或慢查詢日志(--log-slow-queries),關閉並重新打開日志文件。(默認為mysql.log和`hostname`-slow.log)。
如果使用更新日志(--log-update)或二進制日志(--log-bin),關閉日志並且打開有更高序列號的新日志文件。
如果你只使用更新日志,你只需要重新命名日志文件,然后在備份前清空日志。例如,你可以這樣做:
shell> cd mysql-data-directory
shell> mv mysql.log mysql.old
shell> mysqladmin flush-logs

然后做備份並刪除“mysql.old”。 

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM