mysql對binlog的處置解釋。本站提示廣大學習愛好者：（mysql對binlog的處置解釋）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql對binlog的處置解釋正文
但是這裡不盤算對某種存儲引擎的完成細節停止描寫，也不盤算引見各類存儲引擎的優缺陷，只是描寫一下mysql若何處置binlog，並廓清幾個輕易混雜的成績。
Binlog對mysql而言是主要的，重要表現在它的功效上。Mysql官方文檔明白指出，binlog的啟動年夜概會為mysql增長1%的負載，是以在絕年夜多半情形下，binlog都不會成為mysql的機能瓶頸。
Binlog是mysql以二進制情勢打印的日記，它默許不加密，不緊縮。每一個正常的binlog文件頭部，有4個字節的標志，值為0xfe 0x62 0x69 0x6e。LOG_EVENT是binlog裡的單元，即正常情形下binlog依照逐LOG_EVENT的情勢增加。除去頭部的標志，binlog就是一個LOG_EVENT的序列。每一個LOG_EVENT都自力單位，沒有相互援用的關系，它也有本身的二進制頭部，重要是記載了時光戳、類型標志等描寫信息。
Mysql把磁盤操作的完成封裝在IO_CACHE構造裡，這也便利了我們對binlog的研討和描寫，後文假如沒有特殊解釋，讀寫binlog與讀寫IO_CACHE的寄義雷同。
為懂得mysql寫入binlog的進程，可以找一個sql語句的處置進程停止跟蹤。以update為例，在最簡略的情形下，mysql會先挪用為存儲引擎開放的接口ha_update_row，但是履行binlog_query對binlog停止寫操作。如許處置的緣由是，在主從備份的場景下，假如主庫先寫入binlog勝利、在履行update的進程中crash，從庫有能夠履行update勝利，此時主庫重啟以後，與從庫的數據紛歧致。假如update操作產生在事務性的表上，在寫入binlog以後會履行開放接口ha_autocommit_or_rollback，由存儲引擎斷定操作成果。
在主從備份的場景下，主庫相當於server，從庫相當於client，兩邊采取tcp短銜接。從庫收回讀取日記的要求，主庫吸收要求、讀取當地binlog、然後發送給從庫。從庫吸收日記，停止簡略校驗後寫當地日記，稱為relay log。此處從庫的流程專門由一個線程擔任，稱為同步io線程。從庫還有一個線程，稱為同步sql線程。它的行動是，按期讀取relay log，解析並履行同步過去的sql語句。
上面答復幾個成績：
1. binlog的格局？
二進制次序存儲，不加密，不緊縮
2.binlog應用WAL嗎？
No
3.主庫發送binlog，是應用內存裡的copy嗎？
沒法肯定，很有能夠是先從磁盤上讀一份，然後發送。
4. relaylog應用WAL嗎？
Yes。從庫吸收到日記後，會先寫relay log
5. binlog和relaylog的SQL能否分歧？
在收集傳輸准確性靠得住的條件下，yes
提一個成績：
既然binlog不應用WAL，那末在主從場景下，mysql異常以後，主庫和從庫能否會紛歧致呢？
之前有個成績一向沒弄明確：
既然mysql是先做數據操作、再寫binlog，假如寫binlog的時刻掉敗，mysql又crash，數據怎樣辦？
謎底是由存儲引擎決議數據。
可以把mysql和它的存儲引擎離開看，由於mysql只是一個框架，而不是一個完成。
binlog是mysql本身的日記，而事務是由存儲引擎自己包管的。
以update為例，mysql做的工作簡略分為：
1. 修正數據update
2. 寫binlog
3. 假如以後處置的表是一個事務性的表，則commit或rollback
留意此處的update和commit/rollback都由存儲引擎完成，mysql只是站在邏輯的高度上懂得這些操作。
關於事務型的引擎innodb，它自己有日記包管數據的分歧性。在innodb的完成中，update修正數據之前，
會新建一個事務，並樹立一個回滾點。而在innodb供給的commit/rollback接口會提交/回滾事務。
是以對innodb而言，每條SQL語句的事務，其實包括了binlog的寫操作。但是即便是如許，innodb依然沒法包管
binlog和數據的分歧性，由於innodb在寫commit勝利後crash，回滾操作不會回滾binlog。依照手冊上的說法，
把--innodb-support-xa設置為1，同時包管sync_binlog=1，能力包管innodb的binlog和數據分歧。
關於非事務型的引擎myisam，沒有commit/rollback的機遇，是以在異常情形下，數據會和binlog紛歧致。
那末新的成績湧現了：myisam若何處置這個紛歧致呢？
