1、23 | MySQL 是怎么保證數(shù)據(jù)不丟的？2019-01-04 林曉斌 今天這篇文章，我會(huì)繼續(xù)和你介紹在業(yè)務(wù)高峰期臨時(shí)提升性能的方法。從文章標(biāo)題“MySQL是怎 么保證數(shù)據(jù)不丟的？”，你就可以看出來，今天我和你介紹的方法，跟數(shù)據(jù)的可靠性有關(guān)。 在專欄前面文章和答疑篇中，我都著重介紹了WAL機(jī)制（你可以再回顧下第2篇、第9篇、第12 篇和第15篇文章中的相關(guān)內(nèi)容），得到的結(jié)論是：只要redo log和binlog保證持久化到磁盤，就 能確保MySQL異常重啟后，數(shù)據(jù)可以恢復(fù)。 評(píng)論區(qū)有同學(xué)又繼續(xù)追問，redo log的寫入流程是怎么樣的，如何保證redo log真實(shí)地寫入了磁 盤。那么今天，我

2、們就再一起看看MySQL寫入binlog和redo log的流程。 binlog的寫入機(jī)制其實(shí)，binlog的寫入邏輯比較簡(jiǎn)單：事務(wù)執(zhí)行過程中，先把日志寫到binlog cache，事務(wù)提交的時(shí)候，再把binlog cache寫到binlog文件中。 一個(gè)事務(wù)的binlog是不能被拆開的，因此不論這個(gè)事務(wù)多大，也要確保一次性寫入。這就涉及到 了binlog cache的保存問題。 系統(tǒng)給binlog cache分配了一片內(nèi)存，每個(gè)線程一個(gè)，參數(shù) binlog_cache_size用于控制單個(gè)線程 內(nèi)binlog cache所占內(nèi)存的大小。如果超過了這個(gè)參數(shù)規(guī)定的大小，就要暫存到磁盤。 事務(wù)提交

3、的時(shí)候，執(zhí)行器把binlog cache里的完整事務(wù)寫入到binlog中，并清空binlog cache。狀 態(tài)如圖1所示。 圖1 binlog寫盤狀態(tài) 可以看到，每個(gè)線程有自己binlog cache，但是共用同一份binlog文件。 圖中的write，指的就是指把日志寫入到文件系統(tǒng)的page cache，并沒有把數(shù)據(jù)持久化到磁盤，所以速度比較快。 圖中的fsync，才是將數(shù)據(jù)持久化到磁盤的操作。一般情況下，我們認(rèn)為fsync才占磁盤的 IOPS。 write 和fsync的時(shí)機(jī)，是由參數(shù)sync_binlog控制的：1. sync_binlog=0的時(shí)候，表示每次提交事務(wù)都只write，不

4、fsync；2. sync_binlog=1的時(shí)候，表示每次提交事務(wù)都會(huì)執(zhí)行fsync； 3. sync_binlog=N(N1)的時(shí)候，表示每次提交事務(wù)都write，但累積N個(gè)事務(wù)后才fsync。 因此，在出現(xiàn)IO瓶頸的場(chǎng)景里，將sync_binlog設(shè)置成一個(gè)比較大的值，可以提升性能。在實(shí)際的業(yè)務(wù)場(chǎng)景中，考慮到丟失日志量的可控性，一般不建議將這個(gè)參數(shù)設(shè)成0，比較常見的是將其 設(shè)置為1001000中的某個(gè)數(shù)值。 但是，將sync_binlog設(shè)置為N，對(duì)應(yīng)的風(fēng)險(xiǎn)是：如果主機(jī)發(fā)生異常重啟，會(huì)丟失最近N個(gè)事務(wù)的 binlog日志。 redo log的寫入機(jī)制接下來，我們?cè)僬f說redo log的寫

5、入機(jī)制。 在專欄的第15篇答疑文章中，我給你介紹了redo log buffer。事務(wù)在執(zhí)行過程中，生成的redo log是要先寫到redo log buffer的。 然后就有同學(xué)問了，redo log buffer里面的內(nèi)容，是不是每次生成后都要直接持久化到磁盤呢？ 答案是，不需要。如果事務(wù)執(zhí)行期間MySQL發(fā)生異常重啟，那這部分日志就丟了。由于事務(wù)并沒有提交，所以這 時(shí)日志丟了也不會(huì)有損失。 那么，另外一個(gè)問題是，事務(wù)還沒提交的時(shí)候，redo log buffer中的部分日志有沒有可能被持久 化到磁盤呢？ 答案是，確實(shí)會(huì)有。這個(gè)問題，要從redo log可能存在的三種狀態(tài)說起。這三種狀態(tài)，

6、對(duì)應(yīng)的就是圖2 中的三個(gè)顏色 塊。 圖2 MySQL redo log存儲(chǔ)狀態(tài)這三種狀態(tài)分別是：1. 存在redo log buffer中，物理上是在MySQL進(jìn)程內(nèi)存中，就是圖中的紅色部分； 2. 寫到磁盤(write)，但是沒有持久化（fsync)，物理上是在文件系統(tǒng)的page cache里面，也就 是圖中的黃色部分；3. 持久化到磁盤，對(duì)應(yīng)的是hard disk，也就是圖中的綠色部分。 日志寫到redo log buffer是很快的，wirte到page cache也差不多，但是持久化到磁盤的速度就慢 多了。 為了控制redo log的寫入策略，InnoDB提供了innodb_flush

7、_log_at_trx_commit參數(shù)，它有三種 可能取值： 1.設(shè)置為0的時(shí)候，表示每次事務(wù)提交時(shí)都只是把redo log留在redo log buffer中; 2.設(shè)置為1的時(shí)候，表示每次事務(wù)提交時(shí)都將redo log直接持久化到磁盤； 3.設(shè)置為2的時(shí)候，表示每次事務(wù)提交時(shí)都只是把redo log寫到page cache。 InnoDB有一個(gè)線程，每隔1秒，就會(huì)把redo log buffer中的日志，調(diào)用write寫到文件系統(tǒng)的 page cache，然后調(diào)用fsync持久化到磁盤。 注意，事務(wù)執(zhí)行中間過程的redo log也是直接寫在redo log buffer中的，這些redo

8、 log也會(huì)被 線程一起持久化到磁盤。也就是說，一個(gè)沒有提交的事務(wù)的redo log，也是可能已經(jīng)持久化到磁盤的。 實(shí)際上，除了線程每秒一次的輪詢操作外，還有兩種場(chǎng)景會(huì)讓一個(gè)沒有提交的事務(wù)的redo log寫入到磁盤中。 1. 一種是，redo log buffer占用的空間即將達(dá)到 innodb_log_buffer_size一半的時(shí)候，線程會(huì)主動(dòng)寫盤。注意，由于這個(gè)事務(wù)并沒有提交，所以這個(gè)寫盤動(dòng)作只是write，而 沒有調(diào)用fsync，也就是只留在了文件系統(tǒng)的page cache。 2. 另一種是，并行的事務(wù)提交的時(shí)候，順帶將這個(gè)事務(wù)的redo log buffer持久化到磁盤。假設(shè)一個(gè)事

9、務(wù)A執(zhí)行到一半，已經(jīng)寫了一些redo log到buffer中，這時(shí)候有另外一個(gè)線程的事務(wù)B提交，如果innodb_flush_log_at_trx_commit設(shè)置的是1，那么按照這個(gè)參數(shù)的邏 輯， 事務(wù)B要把redo log buffer里的日志全部持久化到磁盤。這時(shí)候，就會(huì)帶上事務(wù)A在redo log buffer里的日志一起持久化到磁盤。 這里需要說明的是，我們介紹兩階段提交的時(shí)候說過，時(shí)序上redo log先prepare， 再寫binlog， 最后再把redo log commit。 如果把innodb_flush_log_at_trx_commit設(shè)置成1，那么redo log在p

10、repare階段就要持久化一次， 因?yàn)橛幸粋€(gè)恢復(fù)邏輯是要依賴于prepare 的redo log，再加上binlog來恢復(fù)的。（如果你印象有點(diǎn)兒模糊了，可以再回顧下第15篇文章中的相關(guān)內(nèi)容）。 輪詢刷盤，再加上恢復(fù)這個(gè)邏輯，InnoDBredo logcommit 每秒一次就認(rèn)為在的時(shí)候就 不需要fsync了，只會(huì)write到文件系統(tǒng)的page cache中就夠了。 通常我們說MySQL的“雙1”配置，指的就是sync_binlog和innodb_flush_log_at_trx_commit都設(shè)置成 1。也就是說，一個(gè)事務(wù)完整提交前，需要等待兩次刷盤，一次是redo log（prepare

11、階段），一次是binlog。 這時(shí)候，你可能有一個(gè)疑問，這意味著我從MySQL看到的TPS是每秒兩萬的話，每秒就會(huì)寫四 萬次磁盤。但是，我用工具測(cè)試出來，磁盤能力也就兩萬左右，怎么能實(shí)現(xiàn)兩萬的TPS？ 解釋這個(gè)問題，就要用到組提交（group commit）機(jī)制了。 這里，我需要先和你介紹日志邏輯序列號(hào)（log sequence number，LSN）的概念。LSN是單調(diào)遞增的，用來對(duì)應(yīng)redo log的一個(gè)個(gè)寫入點(diǎn)。每次寫入長(zhǎng)度為length的redo log， LSN的值就會(huì)加上length。 LSN也會(huì)寫到InnoDB的數(shù)據(jù)頁中，來確保數(shù)據(jù)頁不會(huì)被多次執(zhí)行重復(fù)的redo log。關(guān)于LS

12、N和 redo log、checkpoint的關(guān)系，我會(huì)在后面的文章中詳細(xì)展開。 如圖3所示，是三個(gè)并發(fā)事務(wù)(trx1, trx2, trx3)在prepare 階段，都寫完redo log buffer，持久化到 磁盤的過程，對(duì)應(yīng)的LSN分別是50、120 和160。 圖3 redo log 組提交從圖中可以看到，1. trx1是第一個(gè)到達(dá)的，會(huì)被選為這組的 leader； 2. 等trx1要開始寫盤的時(shí)候，這個(gè)組里面已經(jīng)有了三個(gè)事務(wù)，這時(shí)候LSN也變成了160； 3. trx1去寫盤的時(shí)候，帶的就是LSN=160，因此等trx1返回時(shí)，所有LSN小于等于160的redo log，都已經(jīng)被持

13、久化到磁盤； 4. 這時(shí)候trx2和trx3就可以直接返回了。 所以，一次組提交里面，組員越多，節(jié)約磁盤IOPS的效果越好。但如果只有單線程壓測(cè)，那就 只能老老實(shí)實(shí)地一個(gè)事務(wù)對(duì)應(yīng)一次持久化操作了。 在并發(fā)更新場(chǎng)景下，第一個(gè)事務(wù)寫完redo log buffer以后，接下來這個(gè)fsync越晚調(diào)用，組員可能越多，節(jié)約IOPS的效果就越好。 為了讓一次fsync帶的組員更多，MySQL有一個(gè)很有趣的優(yōu)化：拖時(shí)間。在介紹兩階段提交的時(shí) 候，我曾經(jīng)給你畫了一個(gè)圖，現(xiàn)在我把它截過來。 圖4 兩階段提交 圖中，我把“寫binlog”當(dāng)成一個(gè)動(dòng)作。但實(shí)際上，寫binlog是分成兩步的： 1. 先把binlog

14、從binlog cache中寫到磁盤上的binlog文件；2. 調(diào)用fsync持久化。MySQL為了讓組提交的效果更好，把redo log做fsync的時(shí)間拖到了步驟1之后。也就是說，上面 的圖變成了這樣： 圖5 兩階段提交細(xì)化 這么一來，binlog也可以組提交了。在執(zhí)行圖5中第4步把binlog fsync到磁盤時(shí)，如果有多個(gè)事務(wù)的binlog已經(jīng)寫完了，也是一起持久化的，這樣也可以減少IOPS的消耗。 不過通常情況下第3步執(zhí)行得會(huì)很快，所以binlog的write和fsync間的間隔時(shí)間短，導(dǎo)致能集合到 一起持久化的binlog比較少，因此binlog的組提交的效果通常不如redo lo

15、g的效果那么好。 如果你想提升binlog組提交的效果，可以通過設(shè)置 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count來實(shí)現(xiàn)。 1. binlog_group_commit_sync_delay參數(shù)，表示延遲多少微秒后才調(diào)用fsync; 2. binlog_group_commit_sync_no_delay_count參數(shù)，表示累積多少次以后才調(diào)用fsync。 這兩個(gè)條件是或的關(guān)系，也就是說只要有一個(gè)滿足條件就會(huì)調(diào)用fsync。 所以，當(dāng)binlog_group_commit_sync_delay

16、設(shè)置為0的時(shí) 候，binlog_group_commit_sync_no_delay_count也無效了。 之前有同學(xué)在評(píng)論區(qū)問到，WAL機(jī)制是減少磁盤寫，可是每次提交事務(wù)都要寫redo log和 binlog，這磁盤讀寫次數(shù)也沒變少呀？ 現(xiàn)在你就能理解了，WAL機(jī)制主要得益于兩個(gè)方面： 1. redo log 和 binlog都是順序?qū)懀疟P的順序?qū)懕入S機(jī)寫速度要快； 2. 組提交機(jī)制，可以大幅度降低磁盤的IOPS消耗。 分析到這里，我們?cè)賮砘卮疬@個(gè)問題：如果你的MySQL現(xiàn)在出現(xiàn)了性能瓶頸，而且瓶頸在IO 上，可以通過哪些方法來提升性能呢？針對(duì)這個(gè)問題，可以考慮以下三種方法：1.設(shè)置 bi

17、nlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count參數(shù)，減少binlog的寫盤次數(shù)。這個(gè)方法是基于“額外的故意等待”來實(shí)現(xiàn)的，因此可能會(huì)增加 語句的響應(yīng)時(shí)間，但沒有丟失數(shù)據(jù)的風(fēng)險(xiǎn)。 2.將sync_binlog 設(shè)置為大于1的值（比較常見是1001000）。這樣做的風(fēng)險(xiǎn)是，主機(jī)掉電時(shí) 會(huì)丟binlog日志。 3.將innodb_flush_log_at_trx_commit設(shè)置為2。這樣做的風(fēng)險(xiǎn)是，主機(jī)掉電的時(shí)候會(huì)丟數(shù)據(jù)。 我不建議你把innodb_flush_log_at_trx_commit 設(shè)置成0

18、。因?yàn)榘堰@個(gè)參數(shù)設(shè)置成0，表示redo log只保存在內(nèi)存中，這樣的話MySQL本身異常重啟也會(huì)丟數(shù)據(jù)，風(fēng)險(xiǎn)太大。而redo log寫到文件系統(tǒng)的page cache的速度也是很快的，所以將這個(gè)參數(shù)設(shè)置成2跟設(shè)置成0其實(shí)性能差不多，但這樣做MySQL異常重啟時(shí)就不會(huì)丟數(shù)據(jù)了，相比之下風(fēng)險(xiǎn)會(huì)更小。 小結(jié)在專欄的第2 15篇文章中，我和你分析了，如果redo log和binlogMySQL 篇和第是完整的，是如 何保證crash-safe的。今天這篇文章，我著重和你介紹的是MySQL是“怎么保證redo log和binlog 是完整的”。 希望這三篇文章串起來的內(nèi)容，能夠讓你對(duì)crash-safe

19、這個(gè)概念有更清晰的理解。 之前的第15篇答疑文章發(fā)布之后，有同學(xué)繼續(xù)留言問到了一些跟日志相關(guān)的問題，這里為了方 便你回顧、學(xué)習(xí)，我再集中回答一次這些問題。 問題1： 執(zhí)行一個(gè)update語句以后，我再去執(zhí)行hexdump命令直接查看ibd文件內(nèi)容，為什么沒有看到數(shù)據(jù)有改變呢？ 回答：這可能是因?yàn)閃AL機(jī)制的原因。update語句執(zhí)行完成后，InnoDB只保證寫完了redo log、內(nèi)存，可能還沒來得及將數(shù)據(jù)寫到磁盤。 問題2： 為什么binlog cache是每個(gè)線程自己維護(hù)的，而redo log buffer是全局共用的？ 回答：MySQL這么設(shè)計(jì)的主要原因是，binlog是不能“寫，因此要

20、整個(gè)事務(wù)完成后，再一起寫到文件里。 斷的”。一個(gè)事務(wù)的binlog必須連續(xù) 而redo log并沒有這個(gè)要求，中間有生成的日志可以寫到redo log buffer中。redo log buffer中的 內(nèi)容還能“搭便車”，其他事務(wù)提交的時(shí)候可以被一起寫到磁盤中。 問題3： 事務(wù)執(zhí)行期間，還沒到提交階段，如果發(fā)生crash的話，redo log肯定丟了，這會(huì)不會(huì)導(dǎo) 致主備不一致呢？ 回答：不會(huì)。因?yàn)檫@時(shí)候binlog 也還在binlog cache里，沒發(fā)給備庫(kù)。crash以后redo log和binlog 都沒有了，從業(yè)務(wù)角度看這個(gè)事務(wù)也沒有提交，所以數(shù)據(jù)是一致的。 問題4： 如果binlo

21、g寫完盤以后發(fā)生crash，這時(shí)候還沒給客戶端答復(fù)就重啟了。等客戶端再重連進(jìn)來，發(fā)現(xiàn)事務(wù)已經(jīng)提交成功了，這是不是bug？ 回答：不是。你可以設(shè)想一下更的情況，整個(gè)事務(wù)都提交成功了，redo log commit完成了，備庫(kù)也收到 binlog并執(zhí)行了。但是主庫(kù)和客戶端網(wǎng)絡(luò)斷開了，導(dǎo)致事務(wù)成功的包返回不回去，這時(shí)候客戶端 也會(huì)收到“網(wǎng)絡(luò)斷開”的異常。這種也只能算是事務(wù)成功的，不能認(rèn)為是bug。 實(shí)際上數(shù)據(jù)庫(kù)的crash-safe保證的是： 1. 如果客戶端收到事務(wù)成功的消息，事務(wù)就一定持久化了；2. 如果客戶端收到事務(wù)失?。ū热缰麈I沖突、回滾等）的消息，事務(wù)就一定失敗了；3. 如果客戶端收到“執(zhí)

22、行異常”的消息，應(yīng)用需要重連后通過查詢當(dāng)前狀態(tài)來繼續(xù)后續(xù)的邏輯。此時(shí)數(shù)據(jù)庫(kù)只需要保證內(nèi)部（數(shù)據(jù)和日志之間，主庫(kù)和備庫(kù)之間）一致就可以了。 最后，又到了課后問題時(shí)間。今天我留給你的思考題是：你的生產(chǎn)庫(kù)設(shè)置的是“雙1”嗎？ 如果平時(shí)是的話，你有在什么場(chǎng)景下 改成過“非雙1”嗎？你的這個(gè)操作又是基于什么決定的？ 另外，我們都知道這些設(shè)置可能有損，如果發(fā)生了異常，你的止損方案是什么？你可以把你的理解或者經(jīng)驗(yàn)寫在留言區(qū)，我會(huì)在下一篇文章的末尾選取有趣的評(píng)論和你一起分享和分析。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一起閱讀。 上期問題時(shí)間我在上篇文章最后，想要你分享的是線上“救火”的經(jīng)驗(yàn)。 Lo

23、ng 同學(xué)，在留言中提到了幾個(gè)很好的場(chǎng)景。 其中第3個(gè)問題，“如果一個(gè)數(shù)據(jù)庫(kù)是被客戶端的壓力打滿導(dǎo)致無法響應(yīng)的，重啟數(shù)據(jù)庫(kù)是沒用的?！?，說明他很好地思考了。 這個(gè)問題是因?yàn)橹貑⒅?，業(yè)務(wù)請(qǐng)求還會(huì)再發(fā)。而且由于是重啟，buffer pool被清空，可能會(huì)導(dǎo)致語句執(zhí)行得更慢。 他提到的第4個(gè)問題也很典型。有時(shí)候一個(gè)表上會(huì)出現(xiàn)多個(gè)單字段索引（而且往往這是因?yàn)檫\(yùn)維工程師對(duì)索引原理不夠清晰做的設(shè)計(jì)），這樣就可能出現(xiàn)優(yōu)化器選擇索引合并算法的現(xiàn)象。但實(shí)際上，索引合并算法的效率并不好。而通過將其中的一個(gè)索引改成聯(lián)合索引的方法，是一個(gè)很好的應(yīng)對(duì)方案。 還有其他幾個(gè)同學(xué)提到的問題場(chǎng)景，也很好，很值得你一看。Max

24、 同學(xué)提到一個(gè)很好的例子：客戶端程序的連接器，連接完成后會(huì)做一些諸如show columns的操作，在短連接模式下這個(gè)影響就非常大了。 這個(gè)提醒我們，在review項(xiàng)目的時(shí)候，不止要review我們自己業(yè)務(wù)的代碼，也要review連接器的行為。一般做法就是在測(cè)試環(huán)境，把general_log打開，用業(yè)務(wù)行為觸發(fā)連接，然后通過general log分析連接器的行為。 Manjusaka 同學(xué)的留言中，第二點(diǎn)提得非常好：如果你的數(shù)據(jù)庫(kù)請(qǐng)求模式直接對(duì)應(yīng)于客戶請(qǐng)求，這往往是一個(gè)危險(xiǎn)的設(shè)計(jì)。因?yàn)榭蛻粜袨椴豢煽?，可能突然因?yàn)槟銈児镜囊粋€(gè)運(yùn)營(yíng)推廣，壓力暴增，這樣很容易把數(shù)據(jù)庫(kù)打掛。 在設(shè)計(jì)模型里面設(shè)計(jì)一層

25、，專門負(fù)責(zé)管理請(qǐng)求和數(shù)據(jù)庫(kù)服務(wù)資源，對(duì)于比較重要和大流量的業(yè)務(wù)，是一個(gè)好的設(shè)計(jì)方向。 Vincent 同學(xué)提了一個(gè)好問題，用文中提到的DDL方案，會(huì)導(dǎo)致binlog里面少了這個(gè)DDL語 句，后續(xù)影響備份恢復(fù)的功能。由于需要另一個(gè)知識(shí)點(diǎn)（主備同步協(xié)議），我放在后面的文章中說明。 精選留言 2鍋?zhàn)永蠋熀?，有一個(gè)疑問：當(dāng)設(shè)置sync_binlog=0時(shí)，每次commit都只時(shí)write到page cache，并不 會(huì)fsync。但是做實(shí)驗(yàn)時(shí)binlog文件中還是會(huì)有記錄，這是什么原因呢？是不是 次的輪詢也會(huì)將binlog cache持久化到磁盤？還是有其他的參數(shù)控制呢？ 2019-01-04 線程每

26、秒一作者回復(fù) 你看到的“binlog的記錄”，也是從page cache讀的哦。Page cache是操作系統(tǒng)文件系統(tǒng)上的 好問題 2019-01-044倪大人 老師求解sync_binlog和binlog_group_commit_sync_no_delay_count這兩個(gè)參數(shù)區(qū)別 如果sync_binlog = N binlog_group_commit_sync_no_delay_count = M binlog_group_commit_sync_delay = 很大值這種情況fsync什么時(shí)候發(fā)生呀，min(N,M)嗎？ 感覺sync_binlog搭配binlog_group_co

27、mmit_sync_delay也可以實(shí)現(xiàn)組提交？ 如果 sync_binlog = 0 binlog_group_commit_sync_no_delay_count = 10 這種情況下是累計(jì)10個(gè)事務(wù)fsync一次？ 2019-01-04 作者回復(fù) 好問題，我寫這篇文章的時(shí)候也為了這個(gè)問題去翻了代碼，是這樣的： 達(dá)到N次以后，可以刷盤了，然后再進(jìn)入(sync_delay和no_delay_count)這個(gè)邏輯； Sync_delay如果很大，就達(dá)到no_delay_count才刷；只要sync_binlog=0,也會(huì)有前面的等待邏輯，但是等完后還是不調(diào)fsync 2019-01-06 3W

28、illiamX 為什么 binlog cache 是每個(gè)線程自己維護(hù)的，而 redo log buffer 是全局共用的？這個(gè)問題，感覺還有一點(diǎn)，binlog存儲(chǔ)是以statement或者row格式存儲(chǔ)的，而redo log是以page 頁格式存儲(chǔ)的。page格式，天生就是共有的，而row格式，只跟當(dāng)前事務(wù)相關(guān) 2019-01-04 作者回復(fù) 嗯，這個(gè)解釋也很好。 2019-01-04 2一大只 你是怎么驗(yàn)證的？等于0的時(shí)候雖然有走這個(gè)邏輯，但是最后調(diào)用fsync之前判斷是0，就啥也沒 做就走了回復(fù)老師: 老師，我說的sync_binlog=0或=1效果一樣，就是看語句實(shí)際執(zhí)行的效果，參數(shù)bi

29、nlog_group_c ommit_sync_delay我設(shè)置成了500000微秒，在=1或=0時(shí)，對(duì)表進(jìn)行Insert，然后都會(huì)有0.5秒的等待，也就是執(zhí)行時(shí)間都是0.51 sec，關(guān)閉binlog_group_commit_sync_delay，insert執(zhí)行會(huì)飛快，所以我認(rèn)為=1或=0都是受組提交參數(shù)的影響的。 2019-01-05 作者回復(fù) 非常好 然后再補(bǔ)上我回答的這個(gè)邏輯，就完備了 2019-01-051alias cd=rm -rf事務(wù)A是當(dāng)前事務(wù)，這時(shí)候事務(wù)B提交了。事務(wù)B的redolog持久化時(shí)候，會(huì)順道把A產(chǎn)生的redol og也持久化，這時(shí)候A的redolog狀態(tài)是p

30、repare狀態(tài)么？ 2019-01-28 作者回復(fù) 不是。 說明一下哈，所謂的 redo log prepare，是“當(dāng)前事務(wù)提交”的一個(gè)階段，也就是說，在事務(wù)A提交的時(shí)候，我們才會(huì)走到事務(wù)A的redo log prepare這個(gè)階段。 事務(wù)A在提交前，有一部分redo log被事務(wù)B提前持久化，但是事務(wù)A還沒有進(jìn)入提交階段，是無所謂“redo log prepare”的。 好問題2019-01-281某、人 有調(diào)到非雙1的時(shí)候,在大促時(shí)非核心庫(kù)和從庫(kù)延遲較多的情況。 設(shè)置的是sync_binlog=0和innodb_flush_log_at_trx_commit=2 針對(duì)0和2,在mysq

31、l crash時(shí)不會(huì)出現(xiàn)異常,在主機(jī)掛了時(shí)，會(huì)有幾種風(fēng)險(xiǎn): 1.如果事務(wù)的binlog和redo log都還未fsync,則該事務(wù)數(shù)據(jù)丟失 2. 如果事務(wù)binlog fsync成功,redo log未fsync,則該事務(wù)數(shù)據(jù)丟失。 雖然binlog落盤成功,但是binlog沒有恢復(fù)redo log的能力,所以redo log不能恢復(fù). 不過后續(xù)可以解析binlog來恢復(fù)這部分?jǐn)?shù)據(jù) 3. 如果事務(wù)binlog fsync未成功,redo log成功。 由于redo log恢復(fù)數(shù)據(jù)是在引擎層,所以重新啟動(dòng)數(shù)據(jù)庫(kù),redo log能恢復(fù)數(shù)據(jù),但是不能恢復(fù)serve r層的binlog,則binlo

32、g丟失。 如果該事務(wù)還未從FS page cache里發(fā)送給從庫(kù),那么主從就會(huì)出現(xiàn)不一致的情況4. 如果binlog和redo log都成功fsync,那么皆大歡喜。 老師我有幾個(gè)問題: 1. 因?yàn)閎inlog不能斷,那么binlog做fsync是單線程吧? 如果是的話,那么binlog的write到fsync的時(shí)間,就應(yīng)該是redo log fsync+上一個(gè)事務(wù)的binlog fsync 時(shí)間。 但是測(cè)試到的現(xiàn)象,一個(gè)超大事務(wù)做fsync時(shí),對(duì)其它事務(wù)的提交影響也不大。如果是多線程做fsync,怎么保證的一個(gè)事務(wù)binlog在磁盤上的連續(xù)性？ 2. 5.7的并行復(fù)制是基于binlog組成員

33、并行的,為什么很多文章說是表級(jí)別的并行復(fù)制？ 2019-01-06 作者回復(fù) 1. Write的時(shí)候只要寫進(jìn)去了，fsync其實(shí)很快的。連續(xù)性是write的時(shí)候做的（寫的時(shí)候保證了連續(xù)） 2. 你的理解應(yīng)該是對(duì)的。不是表級(jí)2019-01-06 1永恒記憶主從模式下，內(nèi)網(wǎng)從庫(kù)如果設(shè)置雙1，剛還原的數(shù)據(jù)發(fā)現(xiàn)根本追不上主庫(kù)，所以從庫(kù)設(shè)置了0， 老師后面章節(jié)會(huì)講關(guān)于mysql包括主從監(jiān)控這塊的內(nèi)容嗎。 2019-01-04 作者回復(fù)會(huì)講到 2019-01-04 1往事隨風(fēng)，順其自然 redolog 里面有已經(jīng)提交事物日志，還有未提交事物日志都持久化到磁盤，此時(shí)異常重啟，binl og 里面不是多余記錄

34、的未提交事物，干嘛不設(shè)計(jì)不添加未提交事物不更好 2019-01-04 0miu 老師，關(guān)于BINLOG_GROUP_COMMIT_SYNC_DELAY，BINLOG_GROUP_COMMIT_SYNC_NO_DELAY_COUNT， SYNC_BINLOG三個(gè)參數(shù)，我的理解是： 若SYNC_BINLOG1時(shí)，且設(shè)置了BINLOG_GROUP_COMMIT_SYNC_DELAY和BINLOG_GR OUP_COMMIT_SYNC_NO_DELAY_COUNT兩個(gè)參數(shù)。 例如 sync_binlog=2， BINLOG_GROUP_COMMIT_SYNC_DELAY=1000000， BINLOG

35、_GROUP_COMMIT_SYNC_NO_DELAY_COUNT=3， 那么在執(zhí)行完第1個(gè)事務(wù)后，在第2個(gè)事務(wù)提交時(shí)，會(huì)根據(jù)后續(xù)的事務(wù)提交來判斷fsync等待的時(shí) 間， 若后續(xù)在1秒內(nèi)沒有累積3個(gè)事務(wù)的提交，則會(huì)等待1秒后再做fsync，從SQL語句來看，執(zhí)行第一個(gè)語句很快，第二個(gè)語句需要等待1秒才成功。這時(shí)延時(shí)等待的時(shí)間是BINLOG_GROUP_C OMMIT_SYNC_DELAY所設(shè)置的值。 若執(zhí)行完第1個(gè)事務(wù)后，并行執(zhí)行3個(gè)事務(wù)（1秒內(nèi)完成），則后續(xù)3個(gè)事務(wù)會(huì)同時(shí)做fsync，這時(shí)延時(shí)等待的時(shí)間是BINLOG_GROUP_COMMIT_SYNC_NO_DELAY_COUNT設(shè)置的數(shù)量

36、的事 務(wù)提交的間隔時(shí)間。 也就是sync_binlog+BINLOG_GROUP_COMMIT_SYNC_NO_DELAY_COUNT-1 個(gè)事務(wù)做一次fsync。 我測(cè)試的版本是MySQL官方5.7.24，請(qǐng)老師點(diǎn)評(píng)。 2019-02-01 作者回復(fù) 這兩個(gè)邏輯不建議放到一起算就是按照這樣： 1. 有設(shè)置 BINLOG_GROUP_COMMIT_SYNC_NO_DELAY_COUNT這個(gè)值，（假設(shè)SYNC_D ELAY很大），提交的時(shí)候就得等這么多次才能過； 2. 到了提交階段，又要按照sync_binlog來判斷是否刷盤。 新春快樂2019-02-04 alias cd=rm -rf 老師

37、不好意思，我接著剛才的問題問哈 0并發(fā)事務(wù)的redolog持久化，會(huì)把當(dāng)前事務(wù)的redolog持久化，當(dāng)前事務(wù)的redolog持久化后prepa re狀態(tài)么？redolog已經(jīng)被持久化到磁盤了，那么當(dāng)前事務(wù)提交時(shí)候，redolog變?yōu)閜repare狀態(tài) ，這時(shí)候是從redologbuffer加載還是從磁盤加載？ 2019-01-28 作者回復(fù) 每個(gè)事務(wù)在提交過程的prepare階段，會(huì)把redolog持久化； “當(dāng)前事務(wù)的redolog持久化后prepar e 狀態(tài)么”這個(gè)描述還是不清楚，你用事務(wù)A、事務(wù)B這樣來描述吧 redolog已經(jīng)被持久化到磁盤了，那么當(dāng)前事務(wù)提交時(shí)候， （其實(shí)這里只是“部分”被持久化，因?yàn)檫@個(gè)事務(wù)自己在執(zhí)行的過程中，還會(huì)產(chǎn)生新的日志）， 只需要繼續(xù)持久化剩下的redo log 2019-01-28 0alias cd=rm -rf 您好，我看文章后有倆點(diǎn)疑問，前提條件如果mysql設(shè)置雙1 1、這時(shí)候磁盤中的redolog的狀態(tài)是什么狀態(tài)呢？是pr