深入解析MySQL檢查點課件

summarryMysqllogfileMysql檢查點MysqldoublewritesummarryMysqllogfile基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作基本操作.

為什么要采取異步刷新Why?.

為什么要采取異步刷新Why?為什么要采取異步刷新1Thisisanoptimization2Itcallitwritecombining為什么要采取異步刷新1Thisisanoptimiz關(guān)于log工作原理/index.php/2009/08/innodb-dirtyredo-log-2/關(guān)于log工作原理http://www.orczhou.coinnodb_flush_log_at_trx_commitinnodb_flush_log_at_trx_commitLogbuffer設(shè)置建議mysqladminvar|greplog_bufferinnodb_log_buffer_size|8388608通常設(shè)置范圍8~16M通常8M比較合適，除非有很多blob/text字段操作，或大事務(wù)操作。Logbuffer設(shè)置建議mysqladminvar|Logbuffer設(shè)置showglobalstatuslike'%Innodb_log_waits%';+++|Variable_name|Value|+++|Innodb_log_waits|0|+++Innodb_log_waits

Thenumberoftimesthatthelogbufferwastoosmallandawaitwasrequiredforittobeflushedbeforecontinuing.Logbuffer設(shè)置showglobalstatusinnodb_log_file_size關(guān)于innodb_log_file_size大小設(shè)置如何找到最佳的均衡點呢？/2006/07/03/choosing-proper-innodb_log_file_size/

/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/innodb_log_file_sizeinnodb_log_file_sizeinnodb_log_file_sizeinnodb_log_file_size設(shè)置innodb_log_file_size設(shè)置大概7M每分鐘，那么一個小時是多少呢，7*60=420M,所以單個logfile大小256M大小足夠。2008ByBaronSchwartz/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/innodb_log_file_size設(shè)置大概7M每分鐘，那么一個小時是多少呢，7*60=420M,所修改innodb_log_file_size1干凈的關(guān)閉數(shù)據(jù)庫，刪除日志文件，修改f中innodb_log_file_size，重啟mysql2干凈的關(guān)閉數(shù)據(jù)庫，rename日志文件，修改f中innodb_log_file_size，重啟mysql修改innodb_log_file_size1干凈的關(guān)閉數(shù)Log寫入

LSN實際上對應(yīng)日志文件的偏移量，新的LSN＝舊的LSN+寫入的日志大小。舉例如下：LSN＝1G，日志文件大小總共為600M，本次寫入512字節(jié)，則實際寫入操作為：l求出偏移量：由于LSN數(shù)值遠大于日志文件大小，因此通過取余方式，得到偏移量為400M；寫入日志：找到偏移400M的位置，寫入512字節(jié)日志內(nèi)容，下一個事務(wù)的LSN就是1000000512；Innodb日志機制深入分析Log寫入Innodb日志機制深入分析Innodb日志機制深入分析Innodb日志機制深入分析Checkpoint寫入Innodb實現(xiàn)了FuzzyCheckpoint的機制，每次取到最老的臟頁，然后確保此臟頁對應(yīng)的LSN之前的LSN都已經(jīng)寫入日志文件，再將此臟頁的LSN作為Checkpoint點記錄到日志文件，意思就是“此LSN之前的LSN對應(yīng)的日志和數(shù)據(jù)都已經(jīng)寫入磁盤文件”。恢復(fù)數(shù)據(jù)文件的時候，Innodb掃描日志文件，當(dāng)發(fā)現(xiàn)LSN小于Checkpoint對應(yīng)的LSN，就認為恢復(fù)已經(jīng)完成。Checkpoint寫入的位置在日志文件開頭固定的偏移量處，即每次寫Checkpoint都覆蓋之前的Checkpoint信息。Innodb日志機制深入分析Checkpoint寫入Innodb實現(xiàn)了FuzzyChe管理機制Checkpoint和日志緊密相關(guān)，將日志和Checkpoint一起說明，詳細的實現(xiàn)機制如下：Innodb日志機制深入分析管理機制Checkpoint和日志緊密相關(guān)，將日志和Chec如上圖所示，Innodb的一條事務(wù)日志共經(jīng)歷4個階段：創(chuàng)建階段：事務(wù)創(chuàng)建一條日志；日志刷盤：日志寫入到磁盤上的日志文件；數(shù)據(jù)刷盤：日志對應(yīng)的臟頁數(shù)據(jù)寫入到磁盤上的數(shù)據(jù)文件；寫CKP：日志被當(dāng)作Checkpoint寫入日志文件；Innodb日志機制深入分析如上圖所示，Innodb的一條事務(wù)日志共經(jīng)歷4個階段：Inn對應(yīng)這4個階段，系統(tǒng)記錄了4個日志相關(guān)的信息，用于其它各種處理使用：Logsequencenumber（LSN1）：當(dāng)前系統(tǒng)LSN最大值，新的事務(wù)日志LSN將在此基礎(chǔ)上生成（LSN1+新日志的大小）；Logflushedupto（LSN2）：當(dāng)前已經(jīng)寫入日志文件的LSN；Oldestmodifieddatalog（LSN3）：當(dāng)前最舊的臟頁數(shù)據(jù)對應(yīng)的LSN，寫Checkpoint的時候直接將此LSN寫入到日志文件；Lastcheckpointat（LSN4）：當(dāng)前已經(jīng)寫入Checkpoint的LSN；

對于系統(tǒng)來說，以上4個LSN是遞減的，即：LSN1>=LSN2>=LSN3>=LSN4.Innodb日志機制深入分析對應(yīng)這4個階段，系統(tǒng)記錄了4個日志相關(guān)的信息，用于其它各種處Innodb日志機制深入分析Innodb日志機制深入分析Innodb日志機制深入分析Innodb的數(shù)據(jù)并不是實時寫盤的，為了避免宕機時數(shù)據(jù)丟失，保證數(shù)據(jù)的ACID屬性，Innodb至少要保證數(shù)據(jù)對應(yīng)的日志不能丟失。對于不同的情況，Innodb采取不同的對策：宕機導(dǎo)致日志丟失

Innodb有日志刷盤機制，可以通過innodb_flush_log_at_trx_commit參數(shù)進行控制；日志覆蓋導(dǎo)致日志丟失Innodb日志文件大小是固定的，寫入的時候通過取余來計算偏移量，這樣存在兩個LSN寫入到同一位置的可能，后面寫的把前面寫得就覆蓋了，以“寫入機制”章節(jié)的樣例為例，LSN＝100000000和LSN＝1600000000兩個日志的偏移量是相同的了。這種情況下，為了保證數(shù)據(jù)一致性，必須要求LSN=1000000000對應(yīng)的臟頁數(shù)據(jù)都已經(jīng)刷到磁盤中，也就是要求Lastcheckpoint對應(yīng)的LSN一定要大于1000000000，否則覆蓋后日志也沒有了，數(shù)據(jù)也沒有刷盤，一旦宕機，數(shù)據(jù)就丟失了。Innodb日志機制深入分析Innodb的數(shù)據(jù)并不是實時寫盤1Sharp檢查點。2FuzzycheckpointMysql檢查點的類型1Sharp檢查點。Mysql檢查點的類型通常這里的sharp指的是刷新BP中所有的臟頁到datafile中。臟頁刷新完畢的時候產(chǎn)生一個sharpcheckpoint例如關(guān)閉數(shù)據(jù)庫的時候發(fā)生sharp檢查點大概步驟是1停止所有的更新操作2刷新所有的臟頁到磁盤3寫入當(dāng)前的檢查點信息到日志文件4把檢查點信息寫入到每個datafile中。Sharpcheckpoint介紹通常這里的sharp指的是刷新BP中所有的臟頁到datafi1受參數(shù)innodb_max_dirty_pages_pct影響2percona中引入innodb_adaptive_flushing_method3根據(jù)日志大小進行適時的刷新Fuzzycheckpoint1受參數(shù)innodb_max_dirty_pages_pc每1S若bufferpool中的臟頁比率超過了srv_max_buf_pool_modified_pct=75，則進行Checkpoint，刷臟頁，flushPCT_IO(100)的dirtypages=200若采用adaptiveflushing，則計算flushrate，進行必要的flushflushPCT_IO(100)的dirtypages=200

每10S若bufferpool中的臟頁比率超過了70%，flushPCT_IO(100)的dirtypagesdirtypages=200若bufferpool中的臟頁比率未超過70%，flushPCT_IO(10)的dirtypages=20Checkpoint觸發(fā)條件Checkpoint觸發(fā)條件深入理解內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)內(nèi)存結(jié)構(gòu)中bufferpool中的數(shù)據(jù)結(jié)構(gòu)FreelistLRUlistFlushlist深入理解內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)內(nèi)存結(jié)構(gòu)中bufferpool中的和檢查點相關(guān)的數(shù)據(jù)結(jié)構(gòu)1.LRulist2.Flushlist和檢查點相關(guān)的數(shù)據(jù)結(jié)構(gòu)1.LRulist關(guān)于LRUSpecifiestheapproximatepercentageoftheInnoDBbufferpoolusedfortheoldblocksublist.Therangeofvaluesis5to95.Thedefaultvalueis37(thatis,3/8ofthepool).關(guān)于LRUSpecifiestheapproximate深入解析MySQL檢查點課件關(guān)于FLUShlist實際上就是所有的臟頁的一個先后的修改順序排列關(guān)于FLUShlist實際上就是所有的臟頁的一個先后的修改Gettotalbufferpoolstatistics.*/buf_get_total_list_len(for(i=0;i<srv_buf_pool_instances;i++){buf_pool_t*buf_pool;buf_pool=buf_pool_from_array(i);*LRU_len+=UT_LIST_GET_LEN(buf_pool->LRU);*free_len+=UT_LIST_GET_LEN(buf_pool->free);*flush_list_len+=UT_LIST_GET_LEN(buf_pool->flush_list);}}innodb_max_dirty_pages_pct在數(shù)據(jù)庫源代碼中的體現(xiàn)buf0buf.cGettotalbufferpoolstatistibuf_get_modified_ratio_pct(void){ulintratio;ulintlru_len=0;ulintfree_len=0;ulintflush_list_len=0;buf_get_total_list_len(&lru_len,&free_len,&flush_list_len);ratio=(100*flush_list_len)/(1+lru_len+free_len);/*1+istheretoavoiddivisionbyzero*/return(ratio);}innodb_max_dirty_pages_pct在數(shù)據(jù)庫源代碼中的體現(xiàn)buf0buf.cbuf_get_modified_ratio_pct(voi反映在數(shù)據(jù)庫上的臟頁比率臟頁的比率計算反映在數(shù)據(jù)庫上的臟頁比率臟頁的比率計算可以看出數(shù)據(jù)庫典型反映在數(shù)據(jù)庫上的臟頁比率可以看出數(shù)據(jù)庫典型反映在數(shù)據(jù)庫上的臟頁比率相關(guān)性能參數(shù)在數(shù)據(jù)庫上的反映相關(guān)性能參數(shù)在數(shù)據(jù)庫上的反映Checkpoint觸發(fā)深入解析MySQL檢查點課件Checkpoint觸發(fā)深入解析MySQL檢查點課件計算過去一段時間內(nèi)，flush的平均速度；與當(dāng)前需要的flush速度其中，BUF_FLUSH_STAT_N_INTERVAL=20S不變，計算的仍舊是過去20S內(nèi)的平均flush速度若當(dāng)前所需速度>20S內(nèi)的平均速度，則adaptiveflushing會嘗試進行一次flush操作。flush的dirtypages數(shù)量仍舊是PCT_IO(100)，200個dirtypages。Checkpoint觸發(fā)檢查點深入解析MySQL檢查點課件函數(shù)流程：buf0buf.c

buf_flush_get_desired_flush_rate1.從buf_pool_t結(jié)構(gòu)中，獲得總dirtypage的數(shù)量2.計算最近一段時間之內(nèi)，redo日志產(chǎn)生的平均速度其中，BUF_FLUSH_STAT_N_INTERVAL=20S，20S內(nèi)的平均redo產(chǎn)生速度/**Numberofintervalsforwhichwekeepthehistoryofthesestats.Eachintervalis1second,definedbytherateatwhichsrv_error_monitor_thread()callsbuf_flush_stat_update().*/#defineBUF_FLUSH_STAT_N_INTERVAL20flush的統(tǒng)計信息，每隔20S會被buf_flush_stat_update函數(shù)重置Checkpoint觸發(fā)檢查點函數(shù)流程：刷新臟頁到磁盤的算法首先計算可選的neighborsflush臟頁之前，必須保證臟頁對應(yīng)的日志已經(jīng)寫回日志文件將數(shù)據(jù)拷貝到doublewritememory將doublewritememory寫出到diskdoublewritebuffer的寫，為同步寫，調(diào)用在doublewritebuffer被成功flush到disk之后，對應(yīng)的dirtypages不會再丟失數(shù)據(jù)。此時再將doublewritebuffer對應(yīng)的dirtypages寫出到disk標識當(dāng)前flush操作結(jié)束(buf_flush_end)收集當(dāng)前flush操作的統(tǒng)計信息更新檢查點信息刷新臟頁到磁盤的算法檢查點更新流程流程一每10秒更新檢查點流程二在高IO系統(tǒng)中每1秒更新檢查點檢查點更新流程流程一每10秒更新檢查點Innodb日志機制深入分析為了解決第二種情況導(dǎo)致數(shù)據(jù)丟失的問題，Innodb實現(xiàn)了一套日志保護機制，詳細實現(xiàn)如下：

為了解決第二種情況導(dǎo)致數(shù)據(jù)丟失的問題，Innodb實現(xiàn)了一套日志保護機制，詳細實現(xiàn)如下：“sync”pointisatabout7/8ofinnodb_log_file_size,andthe“async”pointisatabout6/8=3/4ofinnodb_log_file_size.Innodb日志機制深入分析為了解決第二種情況導(dǎo)致數(shù)據(jù)丟失的Innodb日志機制深入分析Innodb日志機制深入分析Innodb日志機制深入分析Innodb日志機制深入分析Innodb日志機制深入分析Innodb日志機制深入分析檢查點的一些總結(jié)mysql檢查點事件受兩個因素的制約：一個是amount,另外一個是age.amount第一個amount,主要innodb_max_dirty_pages_pct參數(shù)控制,這個是控制臟也占Bp的百分比