快捷導(dǎo)航

mysql對binlog的處理說明

更新時間：2011年07月01日 00:31:13 作者：

Mysql和其它開源數(shù)據(jù)庫相比，具有更好的擴(kuò)展性。其主要原因是它提供了存儲引擎的開放接口。喜歡自己折騰數(shù)據(jù)庫的程序員可以從這個接口起步，打造有個性的數(shù)據(jù)庫。

然而這里不打算對某種存儲引擎的實(shí)現(xiàn)細(xì)節(jié)進(jìn)行描述，也不打算介紹各種存儲引擎的優(yōu)缺點(diǎn)，只是描述一下mysql如何處理binlog，并澄清幾個容易混淆的問題。
Binlog對mysql而言是重要的，主要體現(xiàn)在它的功能上。Mysql官方文檔明確指出，binlog的啟動大概會為mysql增加1%的負(fù)載，因此在絕大多數(shù)情況下，binlog都不會成為mysql的性能瓶頸。
Binlog是mysql以二進(jìn)制形式打印的日志，它默認(rèn)不加密，不壓縮。每個正常的binlog文件頭部，有4個字節(jié)的標(biāo)記，值為0xfe 0x62 0x69 0x6e。LOG_EVENT是binlog里的單位，即正常情況下binlog按照逐LOG_EVENT的形式增長。除去頭部的標(biāo)記，binlog就是一個LOG_EVENT的序列。每個LOG_EVENT都獨(dú)立單元，沒有互相引用的關(guān)系，它也有自己的二進(jìn)制頭部，主要是記錄了時間戳、類型標(biāo)記等描述信息。
Mysql把磁盤操作的實(shí)現(xiàn)封裝在IO_CACHE結(jié)構(gòu)里，這也方便了我們對binlog的研究和描述，后文如果沒有特別說明，讀寫binlog與讀寫IO_CACHE的含義相同。
為了解mysql寫入binlog的過程，可以找一個sql語句的處理過程進(jìn)行跟蹤。以update為例，在最簡單的情況下，mysql會先調(diào)用為存儲引擎開放的接口ha_update_row，然而執(zhí)行binlog_query對binlog進(jìn)行寫操作。這樣處理的原因是，在主從備份的場景下，如果主庫先寫入binlog成功、在執(zhí)行update的過程中crash，從庫有可能執(zhí)行update成功，此時主庫重啟之后，與從庫的數(shù)據(jù)不一致。如果update操作發(fā)生在事務(wù)性的表上，在寫入binlog之后會執(zhí)行開放接口ha_autocommit_or_rollback，由存儲引擎判斷操作結(jié)果。
在主從備份的場景下，主庫相當(dāng)于server，從庫相當(dāng)于client，雙方采用tcp短連接。從庫發(fā)出讀取日志的請求，主庫接收請求、讀取本地binlog、然后發(fā)送給從庫。從庫接收日志，進(jìn)行簡單校驗后寫本地日志，稱為relay log。此處從庫的流程專門由一個線程負(fù)責(zé)，稱為同步io線程。從庫還有一個線程，稱為同步sql線程。它的行為是，定期讀取relay log，解析并執(zhí)行同步過來的sql語句。

下面回答幾個問題：

1. binlog的格式？
二進(jìn)制順序存儲，不加密，不壓縮

2.binlog使用WAL嗎？

No
3.主庫發(fā)送binlog，是使用內(nèi)存里的copy嗎？

無法確定，很有可能是先從磁盤上讀一份，然后發(fā)送。

4. relaylog使用WAL嗎？

Yes。從庫接收到日志后，會先寫relay log

5. binlog和relaylog的SQL是否一致？

在網(wǎng)絡(luò)傳輸正確性可靠的前提下，yes

提一個問題：
既然binlog不使用WAL，那么在主從場景下，mysql異常之后，主庫和從庫是否會不一致呢？

之前有個問題一直沒弄明白：
既然mysql是先做數(shù)據(jù)操作、再寫binlog，如果寫binlog的時候失敗，mysql又crash，數(shù)據(jù)怎么辦？
答案是由存儲引擎決定數(shù)據(jù)。
可以把mysql和它的存儲引擎分開看，因為mysql只是一個框架，而不是一個實(shí)現(xiàn)。
binlog是mysql自己的日志，而事務(wù)是由存儲引擎本身保證的。
以update為例，mysql做的事情簡單分為：
1. 修改數(shù)據(jù)update
2. 寫binlog
3. 如果當(dāng)前處理的表是一個事務(wù)性的表，則commit或rollback
注意此處的update和commit/rollback都由存儲引擎實(shí)現(xiàn)，mysql只是站在邏輯的高度上理解這些操作。
對于事務(wù)型的引擎innodb，它本身有日志保證數(shù)據(jù)的一致性。在innodb的實(shí)現(xiàn)中，update修改數(shù)據(jù)之前，
會新建一個事務(wù)，并建立一個回滾點(diǎn)。而在innodb提供的commit/rollback接口會提交/回滾事務(wù)。
因此對innodb而言，每條SQL語句的事務(wù)，其實(shí)包含了binlog的寫操作。然而即使是這樣，innodb仍然無法保證
binlog和數(shù)據(jù)的一致性，因為innodb在寫commit成功后crash，回滾操作不會回滾binlog。按照手冊上的說法，
把--innodb-support-xa設(shè)置為1，同時保證sync_binlog=1，才能保證innodb的binlog和數(shù)據(jù)一致。

對于非事務(wù)型的引擎myisam，沒有commit/rollback的機(jī)會，因此在異常情況下，數(shù)據(jù)會和binlog不一致。
那么新的問題出現(xiàn)了：myisam如何處理這個不一致呢？

您可能感興趣的文章: