3分钟遨游一下MySQL INNODB存储引擎的二次写特征
发布于 2017-04-16 08:39:30 | 137 次阅读 | 评论: 0 | 来源: 网友投递
InnoDB MySQL数据库存储引擎
InnoDB 是 MySQL 上第一个提供外键约束的数据存储引擎，除了提供事务处理外，InnoDB 还支持行锁，提供和 Oracle 一样的一致性的不加锁读取，能增加并发读的用户数量并提高性能，不会增加锁的数量。InnoDB 的设计目标是处理大容量数据时最大化性能，它的 CPU 利用率是其他所有基于磁盘的关系数据库引擎中最有效率的。
本文导读
一个不安全的场景
二次写的引入
二次写是怎么工作的
二次写不是必须的
一个不安全的场景
现在我们面临这样一种场景，就是我们需要将很多数据写入到某个普通文件系统对应的文件里面，并且这些数据是由用户实时生成的，不是我们模拟的，在写的过程中，突然断电了，这个时候大家想想，如果没有任何数据保护机制，是不是会出现数据丢失的情况呢？
二次写的引入
上面的场景是不是和用户插入、修改MySQL的数据非常相似呢？这些实时的数据和插入、修改的数据对应，保存的文件和MySQL的数据保存文件对应，所以MySQL也会面临数据丢失的情况，于是在MySQL里面引入了一种Redo Log文件来实现数据恢复的功能，但是这种日志文件是对页进行物理操作，如果页被破坏了，就没有办法恢复数据了，于是二次写登场了。
二次写是怎么工作的
首先将页复制到二次写，然后二次写中的第一次写就是将其写入到共享表空间文件里面，然后第二写将其写人到数据文件里面去，这样当崩溃的时候，能够从共享表空间里面找到该页的副本从而完成数据恢复。
二次写不是必须的
在不安全场景中我们说到一个很重要的地方，不知道大家注意没有，就是它仅仅描述的是普通文件系统，如果这里不是普通的文件系统，而是提供了一种具备数据超强保护或自身具备二次写类似功能的文件系统，是不是我们就不需要开启二次写功能了呢，比如ZFS文件系统就具备这样的功能。