本篇內(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ù)的原理是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
重慶分公司
重慶分公司
