本篇內(nèi)容主要講解“Mysql 5.5崩潰恢復(fù)的原理是什么”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Mysql 5.5崩潰恢復(fù)的原理是什么”吧!

創(chuàng)新互聯(lián)建站主營(yíng)雙湖網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,成都App制作,雙湖h5小程序開(kāi)發(fā)搭建,雙湖網(wǎng)站營(yíng)銷推廣歡迎雙湖等地區(qū)企業(yè)咨詢

如果你擁有一個(gè)很大的內(nèi)存，那么在享受性能的同時(shí)，你也享受著CRASH時(shí)，恢復(fù)時(shí)漫長(zhǎng)等待的痛苦。
這個(gè)情況在MYSQL 5.5，InnoDB Plugin 1.0.7以后將有所改變

首先來(lái)了解一個(gè)崩潰恢復(fù)的原理 ：

崩潰恢復(fù)（Crash recovery）可以看成兩個(gè)階段，
 第一階段稱為掃描重做日志（Redo scan），這時(shí)InnoDB讀取磁盤(pán)上的Redo Log，并將其存放到一個(gè)Hash表中；
 第二階段應(yīng)用這些Redo Log，將這些日志應(yīng)用到Data Page上。

 在將Redo Log讀取到Buffer Pool的Hash表的過(guò)程中，InnoDB在需要的時(shí)候分配16K的Block用來(lái)存儲(chǔ)這個(gè)這些Redo。
 為了確保Buffer Pool中有足夠剩余空間來(lái)存儲(chǔ)數(shù)據(jù)頁(yè)（Data Page），這樣如果Redo很大的話，這個(gè)Block heap也會(huì)很大。
 這里InnoDB每次讀取一個(gè)Redo的時(shí)候，都會(huì)遍歷一次前面的Heap來(lái)確保，沒(méi)有占用太多的空間。
 所以，如果崩潰前InnoDB的Buffer Pool很大，Dirty Page很多，這個(gè)Heap可能很大，每次遍歷就會(huì)大大降低恢復(fù)時(shí)的效率。

 InnoDB通過(guò)給這個(gè)Heap增加一個(gè)header來(lái)存儲(chǔ)這些信息，解決了上面的問(wèn)題。
 
 恢復(fù)過(guò)程中，另一個(gè)耗時(shí)的操作是發(fā)生在應(yīng)用Redo的階段。
 每一個(gè)應(yīng)用了Redo Log的Data Page都會(huì)被放到一個(gè)叫Flush_list的鏈表中等待Flush，
 而這個(gè)鏈表中的Data Page是嚴(yán)格安裝其LSN順序排列的，
 在InnoDB正常工作的時(shí)候，這總是沒(méi)有問(wèn)題的，因?yàn)镈ata Page的LSN值總是單調(diào)增加的。
 但是在恢復(fù)階段，InnoDB則需要不斷的掃描這整個(gè)鏈表來(lái)確定一個(gè)Data Page的位置。

 InnoDB在恢復(fù)階段，通過(guò)一棵輔助的紅黑樹(shù)（Red-Black Tree）來(lái)存儲(chǔ)這些Page，借此來(lái)避免單純的掃描。
 在恢復(fù)階段結(jié)束后，這棵紅黑樹(shù)將被刪除，F(xiàn)lush_list仍然保持原來(lái)的結(jié)構(gòu)。

測(cè)試結(jié)果；

 在InnoDB Blog中，給出了一個(gè)測(cè)試：
     Plugin1.0.6花費(fèi)7小時(shí)38分鐘恢復(fù)的過(guò)程，
     使用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

到此，相信大家對(duì)“Mysql 5.5崩潰恢復(fù)的原理是什么”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

當(dāng)前名稱：Mysql5.5崩潰恢復(fù)的原理是什么-創(chuàng)新互聯(lián)
URL網(wǎng)址：http://aaarwkj.com/article40/ppiho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、面包屑導(dǎo)航、品牌網(wǎng)站建設(shè)、網(wǎng)站策劃、動(dòng)態(tài)網(wǎng)站、外貿(mào)建站

廣告

聲明：本網(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í)需注明來(lái)源： 創(chuàng)新互聯(lián)