innodb日志管理機(jī)制：

巴中網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站設(shè)計(jì)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)自2013年創(chuàng)立以來到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

1、innodb存儲(chǔ)引擎是支持事務(wù)ACID特性的，這個(gè)理論基本就是一個(gè)關(guān)系型數(shù)據(jù)庫相關(guān)的數(shù)據(jù)恢復(fù)原形設(shè)計(jì)，包括日志、回滾、redo、并發(fā)控制、buffer pool等管理方面，內(nèi)容非常全面；

2、innodb的buffer pool主要用來存儲(chǔ)訪問過的數(shù)據(jù)頁面，他就是一塊連續(xù)的內(nèi)存，通過一定的算法可以使這塊內(nèi)存得到有效的管理，它是數(shù)據(jù)庫系統(tǒng)中擁有大塊內(nèi)存的系統(tǒng)模塊。

  innodb存儲(chǔ)引擎中數(shù)據(jù)的訪問是按照頁（也可以叫塊，默認(rèn)為16KB）的方式從數(shù)據(jù)庫文件讀取到buffer pool中的，然后在內(nèi)存中用同樣大小的內(nèi)存空間來做一個(gè)映射；未來提高數(shù)據(jù)訪問效率，數(shù)據(jù)庫系統(tǒng)預(yù)先就分配了很多這樣的空間，用來與文件中的數(shù)據(jù)進(jìn)行交換；buffer pool的大小可以在配置文件中配置，有參數(shù)innodb_buffer_pool_size的大小來決定，默認(rèn)大小為128MB。在MySQL5.7.4以前，一旦MySQL啟動(dòng)這個(gè)值便不能再做修改，如果要修改只能退出MySQL進(jìn)程，然后修改對(duì)應(yīng)的配置文件來設(shè)置新的buffer pool大小，重啟才能生效。

注意：在MySQL5.7.5之后，可以在MySQL進(jìn)程運(yùn)行的情況下，動(dòng)態(tài)調(diào)整innodb_buffer_pool_size，需要強(qiáng)調(diào)的是，如果buffer pool的大小超過了1GB，應(yīng)該通過調(diào)整innodb_buffer_pool_instances=N，把它分成若干個(gè)instance的做法，來提示MySQL處理請(qǐng)求的并發(fā)能力，因?yàn)閎uffer pool是通過鏈表的方式來管理頁面的，同時(shí)為了保護(hù)頁面，需要在存取的時(shí)候?qū)︽湵砑渔i，在多線程的情況下，并發(fā)去讀寫buffer pool里面緩存的頁面需要鎖的競(jìng)爭和等待。所以修改為多個(gè)instance，每個(gè)instance各自管理自己的內(nèi)存和鏈表，可以提升效率。

3、buffer pool實(shí)現(xiàn)原理：

  buffer pool可以有多個(gè)實(shí)例，可以通過配置文件中的參數(shù)innodb_buffer_pool_instance來設(shè)置，默認(rèn)值為1，實(shí)現(xiàn)多個(gè)實(shí)例的buffer pool主要是為了提高數(shù)據(jù)頁訪問時(shí)的并發(fā)度。每個(gè)實(shí)例的空間大小都是相同的，也就是說系統(tǒng)會(huì)將整個(gè)配置的buffer pool大小按實(shí)例個(gè)數(shù)平分，然后每個(gè)實(shí)例各自進(jìn)行初始化操作；

--注意：在運(yùn)維過程中，看到狀態(tài)參數(shù)innodb_buffer_pool_bytes_data總是比innodb_buffer_pool_size小，就是因?yàn)榭刂祁^信息占用了部分空間。實(shí)際的分配方式是，buffer pool頁面從整個(gè)實(shí)例池中從后向前分配，每次分配一個(gè)頁面，而控制結(jié)構(gòu)使從前向后分配，每次分配一個(gè)buf_block_t結(jié)構(gòu)的大小，知道相遇為止，這樣就將一個(gè)實(shí)例初始化好了。

第一、redo log日志文件管理：

  redo log是用來做數(shù)據(jù)庫crash recovery的，這是數(shù)據(jù)庫保障數(shù)據(jù)安全的重要功能之一。在數(shù)據(jù)庫操作中，它保存了對(duì)innodb表中數(shù)據(jù)的修改記錄，所以也叫日志文件。在innodb存儲(chǔ)引擎中，一般默認(rèn)包括2個(gè)日志文件，新建數(shù)據(jù)庫之后會(huì)有名為ib_logfile0 和ib_logfile1的兩個(gè)文件，如果在啟動(dòng)數(shù)據(jù)庫時(shí)，這兩個(gè)文件不存在，則innodb會(huì)根據(jù)配置參數(shù)或默認(rèn)值，重新創(chuàng)建日志文件；

1.1、LSN 全名叫：log sequence number：

 在innodb內(nèi)部的日志管理中，一個(gè)很重要的概念是LSN，全名叫l(wèi)og sequence number，它用來精確記錄日志位置信息，且是連續(xù)增長的。在innodb中，大小為8個(gè)字節(jié)值，它的增長量是根據(jù)一個(gè)MTR寫入的日志量來計(jì)算的，寫多少日志，LSN就增長多少。（LSN是一個(gè)完全邏輯的概念，每提交一個(gè)物理事務(wù)，LSN就加1）

1.2、在innodb中，通過日志組來管理日志文件，是一個(gè)邏輯定義，包含若干個(gè)日志文件，一個(gè)組中的日志文件大小相等，大小通過參數(shù)來設(shè)置，現(xiàn)在innodb只持有一個(gè)日志組。（在MySQL5.5以前日志組大4G；MySQL5.6.3以后可以設(shè)置的更大到512G）

1.3、redo日志的寫入，都是字節(jié)連續(xù)的，雖然看上去是多個(gè)日志文件，但理解的時(shí)候，完全可以把它想象成一個(gè)文件。（日志組中的每個(gè)日志文件，都有自己的格式，內(nèi)部也是按照大小相等的頁面切割，每個(gè)頁面大小是512字節(jié)）

---注意：如果每次寫入是磁盤塊大小的倍數(shù)，效率才是高的，并且日志將邏輯事務(wù)對(duì)數(shù)據(jù)庫的分散隨機(jī)寫入轉(zhuǎn)化成了順序的512字節(jié)整數(shù)倍數(shù)據(jù)的寫入，這樣就大大提高了數(shù)據(jù)庫的效率。

1.4、redo日志文件的格式：

 每個(gè)日志文件，都有文件頭（普通頁面中，都會(huì)有12個(gè)字節(jié)用來存儲(chǔ)頁面頭信息，這些信息主要用于管理這個(gè)頁面本身的數(shù)據(jù)存儲(chǔ)方式；---注意只有2KB是日志頭，后面是一個(gè)個(gè)連續(xù)的，用來存儲(chǔ)MTR產(chǎn)生的日志頁面）

1.5、MTRinnodb物理事務(wù)：

  它是innodb存儲(chǔ)引擎中一個(gè)很重要的用來保證物理頁面寫入操作完整性及持久性的機(jī)制。之所以被稱為MTR，是因?yàn)樗囊饬x相當(dāng)于一個(gè)mini-transaction，用MTR來表示，這里吧它稱作“物理事務(wù)”，這樣叫是相對(duì)邏輯事務(wù)而言的。

物理事務(wù)既然被稱為事務(wù)，那它同樣有事務(wù)的開始和提交，物理事務(wù)的開始其實(shí)就是對(duì)物理事務(wù)結(jié)構(gòu)體mtr_struct的初始化，物理事務(wù)的提交主要是將所有這個(gè)物理事務(wù)產(chǎn)生的日志寫入到innodb日志系統(tǒng)的日志緩沖區(qū)中，然后等待srv_master_thread線程定時(shí)將日志系統(tǒng)的日志緩沖區(qū)的日志數(shù)據(jù)刷到日志文件中；

---注意：日志緩沖區(qū)的存儲(chǔ)只是一個(gè)暫時(shí)的中間狀態(tài)，日志緩沖區(qū)的大小可以通過參數(shù)innodb_log_buffer_size來設(shè)置，一般都比較小，存儲(chǔ)不了多少日志。

--日志是在邏輯事務(wù)對(duì)數(shù)據(jù)庫做DML操作時(shí)，其所包含的物理事務(wù)MTR所記錄的，針對(duì)所有涉及的buffer pool頁面的修改記錄；

1.6、日志提高性能的關(guān)鍵原因：

①：因?yàn)槿罩臼怯脕碛涗沚uffer pool中page的修改記錄的，所以把page的寫入轉(zhuǎn)化為對(duì)日志的寫入，那此時(shí)page就不需要每次都刷盤，寫page頁面只需要在內(nèi)存中寫入即可，性能會(huì)非常好；

②：通常，一個(gè)頁面是16KB，如果不寫入職，每次寫入的單位還是16KB，即使修改很少的數(shù)據(jù)，也是如此，這樣會(huì)導(dǎo)致無效IO非常嚴(yán)重。

1.7、redo日志大小設(shè)置的問題：

①：如果設(shè)置的非常大，固然性能可能會(huì)很好，但是如果數(shù)據(jù)庫出現(xiàn)異常停機(jī)，此時(shí)可能有很多日志都沒有刷盤，也就是log flushed up to 與 last      checkpointat 兩個(gè)值之間相差太多，恢復(fù)需要比較長的時(shí)間。（redo日志的恢復(fù)是順序的，都是根據(jù)頁面號(hào)的大小排序恢復(fù)的；）

②：日志容量大小的設(shè)置，最好與buffer pool的總大小匹配。如果日志容量太小，buffer pool太大，這就會(huì)導(dǎo)致buffer pool頻繁做檢查點(diǎn)，大的buffer    pool不能被好好利用，如果日志容量過大，而buffer pool很小，此時(shí)buffer page經(jīng)常會(huì)被淘汰出去，增加IO頻次，同時(shí)如果數(shù)據(jù)庫意外宕機(jī)，buffer   pool太小，恢復(fù)起來也會(huì)比較慢；

1.8、redo日志記錄格式：

 innodb的日志是具有邏輯意義的物理日志，所以，日志記錄的格式就不完全是物理信息，而是有一定邏輯意義，基本的格式如下： type(日志類型)，space（表空間ID值），offset（前面space所指定的文件中的頁面號(hào)，以頁面大小為單位），data（表示這條日志記錄對(duì)應(yīng)的數(shù)據(jù)，這個(gè)數(shù)據(jù)是不確定的，根據(jù)不同的type值而不同） ---type類型有很多，比較常用的有： ①：mlog_ibyte、mlog_2bytes、mlog_4bytes、mlog_8bytes：這四個(gè)類型，表示要在某個(gè)位置，寫入一個(gè)（兩個(gè)、四個(gè)、八個(gè)）字節(jié)的內(nèi)容； ②：mlog_write_string：這種類型的日志，其實(shí)和mlog_ibyte是類似的，只是mlog_ibyte是要寫一個(gè)固定長度的數(shù)據(jù)，而mlog_write_string是要寫一段變長的數(shù)據(jù)。 ③：mlog_undo_insert：這個(gè)類型的日志，是在將一條記錄設(shè)置為頁面中的最小記錄時(shí)產(chǎn)生的，因?yàn)橹皇谴騻€(gè)標(biāo)記，存儲(chǔ)的內(nèi)容比較簡單； ④：mlog_init_file_page：這個(gè)類型的日志比較簡單，只有前面的基本頭信息，沒有data部分； ⑤：mlog_comp_page_create：這個(gè)類型只需要村一個(gè)類型及要?jiǎng)?chuàng)建的頁面的位置即可； ⑥：mlog_multi_rec_end：這個(gè)類型的記錄是非常特殊的，它只起一個(gè)標(biāo)記的作用，其存儲(chǔ)的內(nèi)容只有占一個(gè)字節(jié)的類型值。 ⑦：mlog_comp_rec_clust_delete_mark：這個(gè)類型的日志是表示，需要將聚集索引中的某個(gè)記錄打上刪除標(biāo)志； ⑧：mlog_comp_rec_update_in_place：這個(gè)類型的日志記錄更新后的記錄信息，包括所有被更新的列的信息。 ⑨：mlog_comp_page_reorganize：這個(gè)類型的日志表示的是要重組指定的頁面，其記錄的內(nèi)容也很簡單，只需要存儲(chǔ)要重組哪一個(gè)頁面即可；

1.9、日志刷盤時(shí)機(jī)：共有5種時(shí)機(jī)：

①：log buffer空間用完了，這就會(huì)將已經(jīng)產(chǎn)生的log buffer中的日志刷到磁盤中，這是最普遍的一種方式； ②：master線程在后臺(tái)每秒鐘刷一次，將當(dāng)前l(fā)og buffer中的日志刷到磁盤中； ③：每次執(zhí)行DML操作時(shí)，都會(huì)主動(dòng)檢查日志空間是否足夠，如果使用空間的量已經(jīng)超過了一個(gè)預(yù)設(shè)的經(jīng)驗(yàn)值，就會(huì)主動(dòng)刷日志，以保證在后面真正執(zhí)行時(shí)，不會(huì)再執(zhí)行過程中被動(dòng)的刷盤，但這里只會(huì)是寫文件（寫入OS緩沖中）不會(huì)刷盤 ④：在做檢查點(diǎn)的時(shí)候，要保證所有要刷的頁面中LSN值最小的日志已經(jīng)刷入到磁盤，不然，如果此時(shí)數(shù)據(jù)庫宕機(jī)，日志不存在，但數(shù)據(jù)頁面已經(jīng)被修改，從而導(dǎo)致數(shù)據(jù)不一致，就違背了寫日志的原則； ⑤：提交邏輯事務(wù)時(shí)，會(huì)因?yàn)閰?shù)innodb_flush_log_at_trx_commit值的不同，產(chǎn)生不同的行為。如果設(shè)置0，則在事務(wù)提交時(shí)，根本不會(huì)去刷日志緩沖區(qū)，這種設(shè)置是最危險(xiǎn)的；如果設(shè)置2，則在事務(wù)提交時(shí)會(huì)將日志寫入到文件中，但不會(huì)去刷盤，只要操作系統(tǒng)不掛，即使數(shù)據(jù)庫掛了，數(shù)據(jù)還是不會(huì)丟失，一般都是設(shè)置為2；

1.10、redo log刷盤機(jī)制：

當(dāng)提交事務(wù)（邏輯）時(shí)，可以通過參數(shù)innodb_flush_log_at_trx_commit來控制redo log寫入的機(jī)制，參數(shù)值不同，產(chǎn)生的行為不同，主要參數(shù)值如下：

①：innodb_flush_log_at_trx_commit=0   事務(wù)提交時(shí)，MySQL不會(huì)去處理日志緩存區(qū)的內(nèi)容，也不會(huì)去處理日志文件的刷盤操作，由MySQL的后臺(tái)master線程每隔1s將緩存區(qū)的文件刷新到日志文件中；（主機(jī)正常，數(shù)據(jù)庫宕機(jī)后：一般只會(huì)丟失最近1s的事務(wù)） ②：innodb_flush_log_at_trx_commit=1   事務(wù)提交時(shí)，會(huì)將日志緩沖區(qū)的日志寫入到文件中，同時(shí)會(huì)刷新到磁盤中，保證數(shù)據(jù)庫事務(wù)完全不會(huì)丟失。這種設(shè)置影響數(shù)據(jù)庫性能；（主機(jī)正常，數(shù)據(jù)庫宕機(jī)后：數(shù)據(jù)不會(huì)丟失） ③：innodb_flush_log_at_trx_commit=2   事務(wù)提交時(shí)，會(huì)將日志緩存區(qū)日志寫入到文件中，但是不會(huì)刷新到磁盤中。由MySQL的后臺(tái)master線程每隔1s將系統(tǒng)緩存的日志文件刷新到磁盤中；（主機(jī)正常，數(shù)據(jù)庫宕機(jī)后：數(shù)據(jù)不會(huì)丟失）

---注意：如果數(shù)據(jù)庫所在主機(jī)宕機(jī)后：參數(shù)0 會(huì)丟失最近1s的事務(wù)；參數(shù)1 不會(huì)有任何數(shù)據(jù)丟失； 參數(shù)2 會(huì)丟失最近1s的事務(wù)；

第二、數(shù)據(jù)庫undo段管理：

在innodb中支持的回滾段總共有：128X1024=131072個(gè)，在每一個(gè)事務(wù)開始的時(shí)候，都會(huì)分配一個(gè)rseg，就是從長度為128的數(shù)組中，根據(jù)最近使用的情況，找到一個(gè)臨近位置的rseg；

在事務(wù)執(zhí)行的過程中，會(huì)產(chǎn)生兩種回滾日志，一種是insert的undo記錄，一種是update的undo記錄；（因?yàn)閕nnodb把undo分為兩類，一類就是新增，也就是insert，一類是修改，就是update，分類的依據(jù)就是事務(wù)提交后要不要做purge操作，因?yàn)閕nsert是不需要purge的，只要事務(wù)提交了，那這個(gè)回滾記錄就可以丟掉了，而對(duì)于更新和刪除操作而言，如果事務(wù)提交了，還需要為MVCC服務(wù)，那就需要將這些日志放到history list中去，等待去做purge已經(jīng)MVCC的多版本查詢等，所以分為兩類）

2.1、數(shù)據(jù)庫undo日志記錄格式：

 undo有4種類型：

①：trx_undo_insert_rec：記錄插入的undo日志類型，插入記錄用于回滾時(shí)，只需要通過其主鍵就可以實(shí)現(xiàn)回滾操作，所以在undo日志中，只記錄了表ID及主鍵信息； ②：trx_undo_upd_exist_rec：更新一條存在記錄的undo日志類型； ③：trx_undo_upd_del_rec：更新一條已經(jīng)打了刪除標(biāo)志記錄的undo日志類型； ④：trx_undo_del_mark_rec：刪除記錄時(shí)對(duì)記錄打刪除標(biāo)志的undo日志類型； ---注意：與redo日志記錄存儲(chǔ)不同，undo日志的存儲(chǔ)，是不會(huì)垮頁面的； ---注意：使用參數(shù)innodb_force_recovery來決定要不要做回滾操作，如果設(shè)置3或3以上，那么在啟動(dòng)innodb的時(shí)候就不回滾了，這樣可能導(dǎo)致數(shù)據(jù)庫邏輯上的不一致；

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)頁名稱：MySQL——innodb日志管理-創(chuàng)新互聯(lián)
文章起源：http://www.chinadenli.net/article46/deegeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、微信小程序、響應(yīng)式網(wǎng)站、建站公司、網(wǎng)頁設(shè)計(jì)公司、網(wǎng)站設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)