本篇内容主要讲解“Mysql 5.5崩溃恢复的原理是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Mysql 5.5崩溃恢复的原理是什么”吧!
首先来了解一个崩溃恢复的原理 ：
崩溃恢复（Crash recovery）可以看成两个阶段，
第一阶段称为扫描重做日志（Redo scan），这时InnoDB读取磁盘上的Redo Log，并将其存放到一个Hash表中；
第二阶段应用这些Redo Log，将这些日志应用到Data Page上。
恢复过程中，另一个耗时的操作是发生在应用Redo的阶段。
每一个应用了Redo Log的Data Page都会被放到一个叫Flush_list的链表中等待Flush，
而这个链表中的Data Page是严格安装其LSN顺序排列的，
在InnoDB正常工作的时候，这总是没有问题的，因为Data Page的LSN值总是单调增加的。
但是在恢复阶段，InnoDB则需要不断的扫描这整个链表来确定一个Data Page的位置。
测试结果；
在InnoDB Blog中，给出了一个测试：
Plugin1.0.6花费7小时38分钟恢复的过程，
使用Plugin1.0.7则仅仅花了13分56秒，总共快了32倍，
其中扫描Redo阶段快了16倍，应用日志阶段快了35倍。
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崩溃恢复的原理是什么”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
由 dawei
【声明】：聊城站长网内容转载自互联网，其相关言论仅代表作者个人观点绝非权威，不代表本站立场。如您发现内容存在版权问题，请提交相关链接至邮箱：bqsm@foxmail.com，我们将及时予以处理。