十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
本篇内容主要讲解“Mysql 5.5崩溃恢复的原理是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Mysql 5.5崩溃恢复的原理是什么”吧!
创新互联建站主营双湖网站建设的网络公司,主营网站建设方案,成都App制作,双湖h5小程序开发搭建,双湖网站营销推广欢迎双湖等地区企业咨询如果你拥有一个很大的内存,那么在享受性能的同时,你也享受着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崩溃恢复的原理是什么”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!