Mysql日誌維護策略

[這幾天要折騰mysql服務器，因此在網上搜羅了一些維護策略，而後本身總結實驗，下面是個人總結經驗和別人的一些建議]

1、日誌類型：

MySQL有幾個不一樣的日誌文件，能夠幫助你找出mysqld內部發生的事情：

日誌文件	記入文件中的信息類型
錯誤日誌	記錄啓動、運行或中止時出現的問題。
查詢日誌	記錄創建的客戶端鏈接和執行的語句。
二進制日誌	記錄全部更改數據的語句。主要用於複製和即時點恢復。
慢日誌	記錄全部執行時間超過long_query_time秒的全部查詢或不使用索引的查詢。
事務日誌	記錄InnoDB等支持事務的存儲引擎執行事務時產生的日誌。

1.啓動慢查詢日誌：

@MySQL若是啓用了slow_query_log=ON選項，就會記錄執行時間超過long_query_time（默認10s）的查詢（初使表鎖定的時間不算做執行 時間）。日誌記錄文件爲slow_query_log_file[=file_name]，若是沒有給出file_name值， 默認爲主機名，後綴爲-slow.log。若是給出了文件名，但不是絕對路徑名，文件則寫入數據目錄。

【這個能夠在調試mysql性能的時候啓用,能夠找出是哪一個sql指令最浪費時間。生產環境中建議關閉】

2.生產環境中關閉通用查詢日誌：

@因爲打開通用查詢日誌是記錄用戶的全部操做，在生產環境中這個日誌的量是很是大的，因此通常狀況下都是不打開的，myslq默認的該日誌功能也是關閉的，在特殊狀況下才進行打開【通常只有在開發測試環境中，爲了定位某些功能具體使用了哪些SQL語句的時候，纔會在短期段內打開該日誌來作相應的分析。】；

mysql> set global general_log = 1; #1：啓動通用查詢日誌，0：關閉通用查詢日誌

mysql> show global variables like '%general_log%';

+------------------+----------------------------+

| Variable_name    | Value                      |

+------------------+----------------------------+

| general_log      | ON                        | #是否啓用了通用查詢日誌

| general_log_file | /var/run/mysqld/mysqld.log | #日誌路徑

+------------------+----------------------------+

2 rows in set (0.00 sec)

3.按期備份二進制日誌和sql數據：【本地一份，遠程日誌主機一份，存儲主機一份】

@在my.cnf中log-bin = [filename]是啓用二進制日誌，默認以[filename].000001往上記錄的，從啓用log-bin以後【此時最好用mysqldump保存當前的mysql某個庫的數據，由於二進制日誌只是記錄了從如今起到最近一次mysql當機重啓中的全部sql語句】，mysql就會開始記錄每個sql語句，一旦mysql因各類緣由須要重啓，則會產生新的二進制日誌，000001的後綴名會不斷往上自加。如果在mysql當機期間mysql的數據遭到了破壞(如磁盤損壞)，以前的數據所有都被破壞了，這時候這個備份策略就能夠幫你挽回損失。你能夠從二進制日誌中恢復從開始到最近一次mysql重啓這段時間的數據。【二進制日誌中記錄的是每個sql語句，能夠用mysqlbinlog [filename]查看日誌內容】

4.sync_binlog全局變量的取值必定要合適：

@默認狀況下，並非每次寫入時都將二進制日誌與硬盤同步。所以若是操做系統或機器(不只僅是MySQL服務器)崩潰，有可能二進制日誌中最後的語句丟失了。要想防止這種狀況，你可使用sync_binlog全局變量(1是最安全的值，但也是最慢的)，使二進制日誌在每N次二進制日誌寫入後與硬盤同步。對非事務表的更新執行完畢後當即保存到二進制日誌中。

下面解釋下sync_binlog:

「sync_binlog」：這個參數是對於MySQL系統來講是相當重要的，他不只影響到Binlog對MySQL所帶來的性能損耗，並且還影響到MySQL中數據的完整性。對於「sync_binlog」參數的各類設置的說明以下：

sync_binlog=0，當事務提交以後，MySQL不作fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤，而讓Filesystem自行決定何時來作同步，或者cache滿了以後才同步到磁盤。

sync_binlog=n，當每進行n次事務提交以後，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數據強制寫入磁盤。

在MySQL中系統默認的設置是sync_binlog=0，也就是不作任何強制性的磁盤刷新指令，這時候的性能是最好的，可是風險也是最大的。由於一旦系統Crash，在binlog_cache中的全部binlog信息都會被丟失。而當設置爲「1」的時候，是最安全可是性能損耗最大的設置。由於當設置爲1的時候，即便系統Crash，也最多丟失binlog_cache中未完成的一個事務，對實際數據沒有任何實質性影響。從以往經驗和相關測試來看,對於高併發事務的系統來講,「sync_binlog」設置爲0和設置爲1的系統寫入性能差距可能高達5倍甚至更多。

5.若是數據庫有不少的事務型操做，則建議把二進制日誌的回滾上限設置大一些：

@對於事務表，例如BDB或InnoDB表，全部更改表的更新(UPDATE、DELETE或INSERT)被緩存起來，直到服務器接收到COMMIT語句。在該點，執行完COMMIT以前，mysqld將整個事務寫入二進制日誌。當處理事務的線程啓動時，它爲 緩衝查詢分配binlog_cache_size大小的內存。若是語句大於該值，線程則打開臨時文件來保存事務【因此若是bunlog_cache_size足夠大，就避免了過多的磁盤的I/O操做,能夠把數據所有緩存在內存中】。線程結束後臨時文件被刪除。【「max_binlog_cache_size」：和"binlog_cache_size"相對應，可是所表明的是binlog可以使用的最大cache內存大小。當咱們執行多語句事務的時候，max_binlog_cache_size若是不夠大的話，系統可能會報出「Multi- statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage」的錯誤。因此最好也把max_binlog_cache_size也調大些(具體多大看你的服務器了)】

6.儘可能把max_binlog_size設置大些

@「max_binlog_size」：Binlog日誌最大值，通常來講設置爲512M或者1G，但不能超過1G。該大小並不能很是嚴格控制Binlog大小，尤爲是當到達Binlog比較靠近尾部而又遇到一個較大事務的時候，系統爲了保證事務的完整性，不可能作切換日誌的動做，只能將該事務的全部SQL都記錄進入當前日誌，直到該事務結束。

7.下面是mysql環境的狀況：

mysql> show variables like '%binlog%';

+--------------------------------+------------+ | Variable_name | Value | +--------------------------------+------------+
 | binlog_cache_size | 1048576 |
 | innodb_locks_unsafe_for_binlog | OFF |
 | max_binlog_cache_size| 4294967295 |
 | max_binlog_size| 1073741824 |
 | sync_binlog| 0|
+--------------------------------+------------+

8.只對一些必需要備份的庫進行備份 [尤爲是在主從架構中]

@這一點在使用mysql的主從架構的時候特別要注意，由於從服務器是根據主服務器的Binlog來實現同步的。若是對master上每個庫都要進行Binlog備份,則在master的操做極其頻繁的狀況下，mysqlI/O線程的I/O量就會很是大，則可能會有slave端的數據的延時，形成slave端可能有和master端數據不一樣步的狀況。

@MySQL中Binlog的產生量是沒辦法改變的,只要咱們的SQL語句 改變了數據庫中的數據,那麼就 必須將該 SQL語句 所對應的 事件 記錄到 Binlog中。那咱們是否是就沒有辦法優化複製了呢?當 然不是,在MySQL複製環境中,其實是是有8個參數可讓咱們控制須要複製或者須要忽

略而不進行復制的DB 或者Table 的,分別爲:

binlog_do_db:設定哪些數據庫(Schema)須要記錄Binlog; 【j建議master端設置】

binlog_ignore_db:設定哪些數據庫(Schema)不要記錄Binlog; 【建議master端設置】

replicate_do_db:設定須要複製的數據庫(Schema),多個DB用逗號(「,」)分隔;【建議slave端設置】

replicate_ignore_db:設定能夠忽略的數據庫(Schema);【建議slave端設置】

replicate_do_table:設定須要複製的Table;【建議slave端設置】

replicate_ignore_table:設定能夠忽略的Table;【建議slave端設置】

replicate_wild_Do_table:功能同Replicate_Do_Table,但能夠帶通配符來進行設置;【建議slave端設置】

replicate_wild_ignore_table:功能同Replicate_Ignore_Table,可帶通配符設置;【建議slave端設置】

經過上面這八個參數,咱們就能夠很是方便按照實際需求,控制從Master 端到Slave 端的Binlog量儘量的少,從而減少Master 端到Slave端的網絡流量,減小IO 線程的IO 量,還能 減小 SQL線程的解析與應用SQL 的數量,最終達到改善Slave上的數據延時問題。

@實際上,上面這八個參數中的前面兩個是設置在Master端的,然後面六個參數則是設置在

Slave端的。雖然前面兩個參數和後面六個參數在功能上 並無很是直接的關係,可是對於優

化MySQL 的Replication來講均可以啓到類似的功能。固然也有必定的區別,其主要區別以下:

若是在Master端設置前面兩個參數,不只僅會讓Master 端的Binlog 記錄所帶來的IO 量減小,

還會讓Master端的IO線程就能夠減 少 Binlog的讀取量,傳遞給Slave端的IO線程的Binlog量 天然就會較少。這樣作的好處是能夠減小網絡 IO,減小Slave端IO線程的IO量,減小Slave端 的 SQL線程的工做量,從而最大幅度的優化複製性能。固然,在Master端設置也存在必定的弊 端,由於MySQL的判斷是否須要複製某個事件不是根據產生該事件的SQL語句所更改的數據 所在的 DB,而是根據執行SQL語句時刻所在的默認DB,也就是咱們登陸時候指定的DB或 者運行「use database」中所指定的DB。只有當前默認DB和配置中所設定的DB徹底吻合的 時候 IO線程纔會將該事件讀取給Slave的IO線程。因此若是在系統中出如今默認DB和設 定須要複製的 DB不同的狀況下改變了須要複製的DB中某個Table的數據的時候,該事件 是不會被複制到 Slave中去的,這樣就會形成Slave端的數據和Master的數據不一致的狀況出 現。一樣,若是在默認Schema下更改了不須要複製的Schema中的數據,則會被複制到Slave端,當Slave端並無該Schema的時候,則會形成複製出錯而中止。

而若是是在 Slave端設置後面的六個參數,在性能優化方面可能比在Master端要稍微遜色一點,由於無論是須要仍是不須要複製的 事件 都被 會被 IO線程讀取到Slave端,這樣不只僅增長了 網絡 IO量,也給Slave端的IO線程增長了RelayLog的寫入量。可是仍然能夠減小Slave的SQL線程在Slave端的日誌應用量。雖然性能方面稍有遜色,可是在Slave端設置複製過濾機制,能夠保證不會出現由於默認模式的問題而造 成 Slave和Master數據不一致或者複製出錯的 問題。