Mysql 5.5崩潰恢復的原理是什么

本篇內容主要講解“Mysql 5.5崩潰恢復的原理是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Mysql 5.5崩潰恢復的原理是什么”吧!

如果你擁有一個很大的內存，那么在享受性能的同時，你也享受著CRASH時，恢復時漫長等待的痛苦。
這個情況在MYSQL 5.5，InnoDB Plugin 1.0.7以后將有所改變

首先來了解一個崩潰恢復的原理 ：

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

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

 InnoDB通過給這個Heap增加一個header來存儲這些信息，解決了上面的問題。
 
 恢復過程中，另一個耗時的操作是發生在應用Redo的階段。
 每一個應用了Redo Log的Data Page都會被放到一個叫Flush_list的鏈表中等待Flush，
 而這個鏈表中的Data Page是嚴格安裝其LSN順序排列的，
 在InnoDB正常工作的時候，這總是沒有問題的，因為Data Page的LSN值總是單調增加的。
 但是在恢復階段，InnoDB則需要不斷的掃描這整個鏈表來確定一個Data Page的位置。

 InnoDB在恢復階段，通過一棵輔助的紅黑樹（Red-Black Tree）來存儲這些Page，借此來避免單純的掃描。
 在恢復階段結束后，這棵紅黑樹將被刪除，Flush_list仍然保持原來的結構。

測試結果；

 在InnoDB Blog中，給出了一個測試：
     Plugin1.0.6花費7小時38分鐘恢復的過程，
     使用Plugin1.0.7則僅僅花了13分56秒，總共快了32倍，
     其中掃描Redo階段快了16倍，應用日志階段快了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崩潰恢復的原理是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！