fast recovery for innodb1.07 in Mysql 5.5

如果你擁有一個很大的記憶體，那麼在享受效能的同時，你也享受著CRASH時，恢復時漫長等待的痛苦。
http://www.mysqlperformanceblog.com/2007/07/17/innodb-recovery-is-large-buffer-pool-always-better/
這個情況在MYSQL 5.5，InnoDB Plugin 1.0.7以後將有所改變 [@more@]

（以下內容部分轉載）

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

崩潰恢復（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 7h38m
1.0.7 (and Plugin 1.1) is better 16.95x on scan, 35.33x on apply, 32.87x overall

參考文獻：

Changes in InnoDB Plugin 1.0.7 ：
http://dev.mysql.com/doc/innodb-plugin/1.1/en/innodb-changes-107.html
Introduction to MySQL 5.5
http://dev.mysql.com/tech-resources/articles/introduction-to-mysql-55.html
InnoDB recovery is now faster…much faster
http://blogs.innodb.com/wp/2010/04/innodb-performance-recovery/