您好,登錄后才能下訂單哦!
本篇內(nèi)容主要講解“Mysql 5.5崩潰恢復(fù)的原理是什么”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學(xué)習(xí)“Mysql 5.5崩潰恢復(fù)的原理是什么”吧!
如果你擁有一個很大的內(nèi)存,那么在享受性能的同時,你也享受著CRASH時,恢復(fù)時漫長等待的痛苦。
這個情況在MYSQL 5.5,InnoDB Plugin 1.0.7以后將有所改變
首先來了解一個崩潰恢復(fù)的原理 :
崩潰恢復(fù)(Crash recovery)可以看成兩個階段,
第一階段稱為掃描重做日志(Redo scan),這時InnoDB讀取磁盤上的Redo Log,并將其存放到一個Hash表中;
第二階段應(yīng)用這些Redo Log,將這些日志應(yīng)用到Data Page上。
在將Redo Log讀取到Buffer Pool的Hash表的過程中,InnoDB在需要的時候分配16K的Block用來存儲這個這些Redo。
為了確保Buffer Pool中有足夠剩余空間來存儲數(shù)據(jù)頁(Data Page),這樣如果Redo很大的話,這個Block heap也會很大。
這里InnoDB每次讀取一個Redo的時候,都會遍歷一次前面的Heap來確保,沒有占用太多的空間。
所以,如果崩潰前InnoDB的Buffer Pool很大,Dirty Page很多,這個Heap可能很大,每次遍歷就會大大降低恢復(fù)時的效率。
InnoDB通過給這個Heap增加一個header來存儲這些信息,解決了上面的問題。
恢復(fù)過程中,另一個耗時的操作是發(fā)生在應(yīng)用Redo的階段。
每一個應(yīng)用了Redo Log的Data Page都會被放到一個叫Flush_list的鏈表中等待Flush,
而這個鏈表中的Data Page是嚴(yán)格安裝其LSN順序排列的,
在InnoDB正常工作的時候,這總是沒有問題的,因為Data Page的LSN值總是單調(diào)增加的。
但是在恢復(fù)階段,InnoDB則需要不斷的掃描這整個鏈表來確定一個Data Page的位置。
InnoDB在恢復(fù)階段,通過一棵輔助的紅黑樹(Red-Black Tree)來存儲這些Page,借此來避免單純的掃描。
在恢復(fù)階段結(jié)束后,這棵紅黑樹將被刪除,F(xiàn)lush_list仍然保持原來的結(jié)構(gòu)。
測試結(jié)果;
在InnoDB Blog中,給出了一個測試:
Plugin1.0.6花費7小時38分鐘恢復(fù)的過程,
使用Plugin1.0.7則僅僅花了13分56秒,總共快了32倍,
其中掃描Redo階段快了16倍,應(yīng)用日志階段快了35倍。
以下是原文:
configuration parameters:
–innodb-buffer-pool-size=18g
–innodb-log-file-size=2047m
–innodb-adaptive-flushing=0
–innodb-io-capacity=100
The latter two are used to throttle flushing in order to maximize the number of dirty pages.
It took only about 20 min of running a workload to arrive to the test dataset, including cache prewarming.
So at time of crash we had:
Modified db pages 1007907
Redo bytes: 3050455773
And the recovery times were:
Plugin 1.0.7 (also Plugin 1.1): 1m52s scan, 12m04s apply, total 13m56s
Plugin 1.0.6: 31m39s scan, 7h06m21s apply, total 7h48m
1.0.7 (and Plugin 1.1) is better 16.95x on scan, 35.33x on apply, 32.87x overall
到此,相信大家對“Mysql 5.5崩潰恢復(fù)的原理是什么”有了更深的了解,不妨來實際操作一番吧!這里是億速云網(wǎng)站,更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。