MySQL二進制日誌（binary log）總結
本文出處：http://www.cnblogs.com/wy123/p/7182356.html
（保留出處並非什麽原創作品權利，本人拙作還遠遠達不到，僅僅是為了鏈接到原文，因為後續對可能存在的一些錯誤進行修正或補充，無他）
今天無意中發現了一個雲棲社區舉行的MySQL“第一季：挑戰玄慚之 慢SQL性能優化賽”，在測試服務器上執行其測試腳本寫入數據的時候報錯提示如下，
Multi-statement transaction required more than ‘max_binlog_cache_size‘ bytes of storage,increase this mysqld variable and try agagin
提示max_binlog_cache_size空間不足，因為開啟了二進制日誌，之前是默認設置沒有大批量的事務性操作，沒有遇到該問題，這一次一開始就遇到一個較大的事務性操作就失敗了。
之後修改binlog_cache_size的大小之後，問題解決。
由於使用的是默認的innodb引擎，開啟了二進制日誌，
對於事務性的操作，是要事物完成的時候寫入二進制日誌，事物提交之前，執行的寫入性操作會被緩存起來，直到整個事物完成，mysqld進程會將整個事物寫入二進制日誌。
當事物開始的時候，會按照binlog_cache_size系統變量指定的值分配內容空間，如果指定的binlog_cache_size緩存空間不夠，執行的事務性操作回滾並提示失敗。
順便總結一下二進制日誌（binary log）以及其相關參數信息
什麽是二進制日誌？
用來記錄操作MySQL數據庫中的寫入性操作（增刪改，但不包括查詢），相當於sqlserver中的完整恢復模式下的事務日誌文件。
二進制日誌的作用？
1，用於復制，配置了主從復制的時候，主服務器會將其產生的二進制日誌發送到slave端，slave端會利用這個二進制日誌的信息在本地重做，實現主從同步
2，用戶恢復，MySQL可以在全備和差異備份的基礎上，利用二進制日誌進行基於時間點或者事物Id的恢復操作。原理雷同於主從復制的日誌重做。
二進制日誌（binary log）的相關參數信息
1，開啟二進制日誌
開啟二進制日誌，需要制定一個log-bin參數的路徑，也即：log_bin=/var/lib/mysql/mysql-bin
開始二進制日誌之後會自動生成一個管理二進制日誌的log_bin_index文件。log_bin也顯示為on
2，二進制日誌文件的格式
二進制日誌的格式由參數binlog_format控制，二進制日誌有三種模式，基於語句(statement)的，基於行的（row），以及結合前兩者的混合模式（mixed）
基於語句的二進制功能有一些硬傷（個人認為），比如同樣的update語句中的利用當前時間的now更新操作，在主服務器和從服務器上，主從復制得到的結果是不一樣的。
基於行的二進制解決了語句語句的一些缺陷，但是某些情況下回產生大量的日誌，比如一個update操作更新了100W行數據，如果是基於行的二進制日誌，結果就是產生了100W條日誌
基於混合模式的，結合上述兩種方式的優點。
可以在配置文件中設置：binlog_format = MIXED
3，二進制日誌的記錄時機
二進制日誌記錄可以使同步的，也即事物提交之後就寫入二進制日誌，也可以是異步的，由操作系統的磁盤緩存覺得什麽時候寫入磁盤。
由參數sync_binlog= n來控制，設置sync_binlog = 1的話，表示最高安全級別的寫入（但也不能保證不丟失任何事物日誌），相當於是一種安全寫入模式，不過對性能有一定的影響。
個人覺得，如果是事務性的引擎，本身就是為了保證事物安全的，沒理由不把sync_binlog 設置為1。
據說設置為sync_binlog設置為1也會潛在丟失一個事務日誌的可能性，但是還沒想明白為什麽會丟失，因為既然是事務性引擎，還有一層undo或者redo日誌在做後盾啊？
4，二進制日誌的單個文件大小
二進制日誌的大下就是單個日誌文件的最大限制，正常情況下都不會超過設置的最大文件的大小限制，超過設置的最大限制之後，會發生日誌滾動，也即重新生成一個二進制日誌文件。
max_binlog_size = 100M
這裏顯示的104857600單位是字節，也即104857600/1024/1024 = 100M
5，二進制日誌的清理
二進制日誌滾動之後會生成新的文件來存儲日誌，日誌文件逾期之後會自動刪除，否則會產生源源不斷的日誌文件
比如可以設置過期時間為2，可配值為：expire_logs_days = 2，超過兩天的二進制日誌會被自動刪除。
可以通過命令show master logs 查看當前的二進制日誌文件個數
6，二進制日誌文件的滾動
1）正常情況下，記錄滿之後，自動滾動，後綴名+1
2）重啟mysql服務之後，自動滾動，不管時候記錄滿
3）手動滾動，執行flush logs命令，如下執行flush logs之後，重新生成了一個二進制日誌文件
4）手動刪除二進制日誌
可以通過命令purge binary logs to fileName刪除指定fileName之前的文件
可以通過命令purge binary logs before ‘2017-03-10 10:10:00‘刪除指定時間之前的文件
刪除指定日誌purge binary logs before date_sub( now( ), interval 7 day);
瀟湘大神是purge master logs before date_sub( now( ), interval 7 day),應該是一個效果（binary和master關鍵詞）？
7，二進制日誌的綁定（或者排除）的數據庫
可以設置某些數據庫開啟二進制日誌，或者某些數據庫不開啟二進制日誌
# binlog_do_db:設置master-slave時使用;
# binlog-ignore-db:設置哪個數據庫不記錄日誌;
MySQL5.7.18中設置了（my.cnf中配置了），但是查詢的時候好像沒用?
8，二進制日誌的緩存以及緩存大小配置
binlog_cache_size的大小，一開始提到的問題，當事物開始的時候，會按照binlog_cache_size系統變量指定的值分配內容空間，如果指定的binlog_cache_size緩存空間不夠則會報錯並回滾事物
這裏顯示的記錄的單位同樣是字節，除以兩個1024之後就是以MB為單位的容量了，這裏的20971520 /1024/1024就相當於20MB了。
如果有較大的事務性操作，比如在測試的時候，必須要將此緩存設置的相對較大一些，否則語句無法成功執行
max_binlog_cache_size語binlog_cache_size的區別在於前者是實例級別的cache，後者是Session級別的cache，如果並發量很大，就需要考慮將max_binlog_cache_size設置的稍微大一些。
max_binlog_cache_size默認是是4GB，最大值也是4GB，這裏為了測試設置的是100MB（104857600/1024.0/1024.0）
max_binlog_cache_size設置的最大內存大小為4GB，如果服務器內容較大，比如128GB或者更大，max_binlog_cache_size默認為最大也無傷大雅，因為要保證並發成功寫入。
至於對於Session級別的binlog_cache_size大小，可以根據業務情況自行調整，個人覺得設置的稍微大一點也問題不大，畢竟，有一些定時作業之類的數據提取或者merge之類的操作可能會產生大量的日誌。
據說是可以通過查看binlog_cache_disk_use 與 binlog_cache_use來判斷binlog_cache_size是否需要調整。
但是在MySQL5.7.18中並沒有發現這個參數
9，二進制日誌其他參數
max_binlog_stmt_cache_size針對非事務語句，非事務性的參數暫不關心它了
記得某次看到過某大師說過，innodb引擎優勢不僅僅在事務性的支持上，與非事物引起的myisam引擎相比，讀取性能上差距越來越小，MySQL因此將innodb設置為默認引擎。
放棄myisam，投奔innodb是正道。
binlog_checksum 用作復制的主從校檢。暫時沒有研究過這個參數，暫不論
詳細參考想想大神的文章http://www.cnblogs.com/kerrycode/p/6610874.html 。
總結：
MySQL二進制日誌不僅僅作用於功能性（master-slave復制）的，還作用於安全性（二進制日誌）以及開啟了二進制日誌情況下的事務性操作，因此對於生產環境，可以認為是一個必不可少的配置。
同時，其各種參數又會影響到某些操作，因此二進制日誌的參數要格外的重視，確保數據庫在使用時在功能性和可用性上得到保證。
參考：http://www.cnblogs.com/kerrycode/p/6610874.html
《塗抹MySQL》
以及各種翻書，網上資料
行動起來，可以改變思維模式以及畏懼心理。
MySQL二進制日誌（binary log）總結