|
MySQL数据库InnoDB存储引擎的Redo Log 记录的就是这种物理和逻辑相结合的日志。 物理和逻辑结合的日志(Physiological Log)
这种日志有2个特点:
A. 物理到page. 将操作细分到页级别。为每个页上的操作单独记日志。
比如,一个Insert分别在2个B-Tree的节点上做了插入操作，那么就分别为每一个页的操作记录一条日志。
B. Page内采用逻辑的日志。比如对一个B-Tree的页内插入一条记录时，物理上来说要修改Page Header的
内容(如,页内的记录数要加1)，要插入一行数据到某个位置，要修改相邻记录里的链表指针，要修改Slot的
属性等。从逻辑上来说，就是在这个页内插入了一行记录。因此Page内的逻辑日志只记录：’这是一个
插入操作’和’这行数据的内容‘。 MySQL数据库InnoDB存储引擎的Redo Log 记录的就是这种物理和逻辑相结合的日志。
使用页内的逻辑日志，可以减少日志占用的空间。但是它毕竟还是逻辑日志，上面提到的2个问题能够避免吗？
A. 页面内的部分执行的情况可以认为不存在了。因为整个页面的操作是原子操作，在完成之前是不会写
到磁盘上的。
B. 操作一致性的问题仍然存在。如果在写一个Page到磁盘时发生了故障，可能导致Page Header的记
录数被加1了，但是数据没有刷新到磁盘上，总之页面上的数据不一致了。 好在这个问题被缩小到了一个页面的范围内，因此比较容易解决。InnoDB存储引擎中用Double Write的方法
来解决这个问题。 - Double Write
Double Write的思路很简单:
A. 在覆盖磁盘上的数据前，先将Page的内容写入到磁盘上的其他地方(InnoDB存储引擎中的doublewrite
buffer，这里的buffer不是内存空间，是持久存储上的空间).
B. 然后再将Page的内容覆盖到磁盘上原来的数据。 如果在A步骤时系统故障，原来的数据没有被覆盖，还是完整的。 -(可继续应用redo 将旧值读入内存-修改->copy到双写file,然后从内存写入数据文件）
如果在B步骤时系统故障，原来的数据不完整了，但是新数据已经被完整的写入了doublewrite buffer. -(可直接将双写区的文件覆盖到数据文件)
因此系统恢复时就可以用doublewrite buffer中的新Page来覆盖这个不完整的page. Double write 显然会曾加磁盘的IO。直觉上IO次数增加了1倍，但是性能损失并不是很大。Peter在
innodb-double-write中说性能损失不超过5-10%。应该是因为多数情况下使用了批量写入的缘故。
A. Double write buffer是一段连续的存储空间，可以顺序写入。
B. Double write有自己的写buffer.
C. 先将多个要做doublewrite的page写入内存的buffer，然后再一起写到
| 
发表于 2015-3-15 22:30
