MySQL-事务的实现-redo


MySQL中事务:
  1. 事务的实现:
     ACID:
    • 原子性(A : Atomicity)
    • 一致性(C : consistency )
    • 隔离性(I : isolation)
    • 持久性(D : durability )
  1. 实现方式:
    • 隔离性:通过锁来实现
    • 原子性和持久性:通过redo log 来实现
    • 一致性:通过undo来实现
  1. redo 和 undo 比较:
        都是恢复操作:
    1. redo:恢复提交事务修改的页操作
    2. undo: 回滚行记录到某个特定版本
       记录内容不同:
    1. redo: 是物理日志,记录的是物理的修改操作
    2. undo: 是逻辑日志,根据每行记录进行记录
       读取方式不同:
    1. redo : 在数据库运行时,不需要读取操作(注:数据库恢复时,才用redo)
    2. undo : 在数据库运行时,需要随机读取(注:回滚时用)
 
 
redo-在事务中的应用
1.基本概念
【事务持久性:D】-- 【重做日志来实现】
【持久性构成】:1.重做日志缓冲(redo log buffer) ,是易失的 2.重做日志文件(redo log file),是持久的
【持久性原理】:InnoDB是事务的存储引擎,通过Flush Log at Commit机制实现事务的持久性。即:当事务提交(Commit)时,必须先将事务的所有日志(这里只重做日志)写入到重做日志文件中,进行持久化,待事务的commit完成才算完成。
【事务的所有日志】:在InnoDB中,事务的所有日志有两部分:redo log 和 undo log 
 
【fsync操作】:为了确保每次重做日志都写入重做日志文件,在将重做日志缓冲写入重做日志文件后,InnoDB存储引擎都需要调用一次fsync操作。
【innodb_flush_method = O_DIRECT/NULL】: 控制InnoDB数据文件和redo log 文件打开,刷写模式。
     1.设置为NULL时,默认是:fsync选项。过程:重做日志缓冲先写入文件系统缓存,再进行fsync(将日志刷新到重做日志文件 )操作。依赖磁盘的性能。
     2.设置为O_DIRECT,过程:调用用O_DIRECT打开数据文件, 然后调用:fsync(),将所有刷新到数据和log文件中。不经过操作系统缓存,避免两次写操作
【非持久性】:通过手工设置非持久性来提高数据库性能。
     原理:事务提交时,日志不写入重做日志文件,而是等待一个周期后,再执行fsync操作。不是强制每次提交都fsync,可以显著提高性能。
      弊端:如果数据库发生宕机,由于部分日志未刷新到磁盘,会丢失最后一段的事务。
【innodb_flush_log_at_trx_commit = 0/1/2】:该参数控制重做日志刷新到磁盘的策略。
     1 : 默认是1,表示事务提交时必须调用一次fsync,<redo log刷新条件之一:事务提交前必刷新到日志文件>。遵循ACID的持久性
     0 : 事务提交时,不进行写重做日志操作.写的操作仅在master Thread中完<redo log 刷新条件之二>,大概每隔1秒执行一次fsync操作.在1秒内有数据库宕机丢数据的风险.
     2 : 写重做日志文件,但仅仅写入文件系统缓存中,不进行fsync操作。仅数据库宕机系统正常,不会丢数据。 系统宕机,缓存中未刷新到重做日志文件的那部分事务会丢失.
总结:0和2能提高事务提交性能,但是这种情况丧失了事务的ACID特性,因此在大量执行insert操作时,在最后执行一次commit操作。这样回滚时可以回滚到事务最开始的状态.
 
Innodb存储引擎使用中,为了遵循持久性和一致性,关于复制的设置:
     1.如果启用二进制日志(binlog),设置: sync_binlog=1;
     2.同时也设置: innodb_flush_log_at_trx_commit=1.
 
【sync_binlog = N】:
     N=0,事务提交后,不做fsync之类的磁盘同步指令,刷新binlog_cache到磁盘文件,而是让文件系统自行决定什么时间同步。性能高,但是有丢失数据的风险.
     N=1,1次事务提交后,执行fsync操作,将binlog chace同步到磁盘文件。这种选择是最安全的,但是是最慢的.
【binlog和redo log比较】:
     1.产生层面不同
     redo log: 是在存储引擎层产生,只针对InnoDB存储引擎
     binlog:在数据库上层产生的.MySQL中任何存储引擎对数据库的更改都会产生二进制日志.
     2.记录内容形式不同
     redo log: 是物理格式的日志,记录的是对于每个页的修改.
     binlog: 是一种逻辑日志,记录的是sql语句.
     3.写入磁盘时间不同
     redo log: 在事务进行中不断的写入.不随事务的提交而提交,不是顺序写入的.
     binlog: 在事务提交后进行写入.
 
2.日志块的结构
在InnoDB存储引擎中,重做日志都是以512字节进行存储的.也就是说重做日志缓冲,重做日志文件都是以块(block)的方式进行保存.称为:重做日志块(redo log block),大小:512字节.
如果一个页中产生的重做日志大于512字节,就分割成多个重做日志块就行存储.
重做日志块的大小和磁盘扇区的大小一样,512字节,因此重做日志的写入可以保证原子性不需要doublewrite技术.
 
日志块的组成:日志本身,日志块头(log block header),日志块尾(log block tailer)
 
 
Log Block Header 解析:
 
LOG_BLOCK_HDR_NO:4字节
log buffer由log block组成,在内部就像一个数组,而LOG_BLOCK_HDR_NO,用来标记这个数组中的位置。改制必须大于0,允许最大2G;如果在日志刷新写入段时,是第一个日志块,最高位就设置成1.
LOG_BLOCK_DATA_LEN:2字节
表示LOG_BLOCK所占用的大小,被写满时,该值为:0x200,表示全部block空间,即占用512字节。
LOG_BLOCK_FIRST_REC_GROUP:占用2字节
表示LOG_BLOCK中第一个日志所在的偏移量。如果LOG_BLOCK_FIRST_REC_GROUP=LOG_BLOCK_DATA_LEN 表示log block不包含新的日志。
LOG_BLOCK_CHECKPOINT_NO:4字节
表示:LOG_BLOCK最后被写入时的检查点。如果此时log block还没写满,只能等下次log flush 时,才会更新。
 
关于一个事务占用两个log block的图:
事务T1的重做日志占用:696字节
事务T2的重做日志占用:100字节
有图知道:事务T1 696字节,占用两个log block,左侧的log block中 LOG_BLOCK_FIRST_REC_GROUP=12,即第一个日志开始的位置。
在第二个block中,由于包含了T1的重做日志,因此事务T2的重做日志才是block中的第一个日志,即 LOG_BLOCK_FIRST_REC_GROUP=(12+200)=212
 
3.重做日志组(log group)
 
log group为重做日志组,里面有多个重做日志文件。源码中支持log group的镜像功能,但已禁用了,因此InnoDB存储引擎实际只有1个log group。
 
log group 是逻辑上的概念!!!
 
重做日志存储的就是之前在log buffer中保存的块,因此也是根据块的方式进行物理存储的管理。block=512bytes。
 
InnoDB存储引擎运行过程中, log buffer根据一定的规则将log block刷新到磁盘:
     1.事务提交时
     2.当log buffer中一半的空间已经被使用
     3.log checkpoint时
 
redo log file的写入顺序:
     log block 写入追加到redo log file的最后部分,当一个redo log file写满时,会写入下一个redo log file。 这种方式:round-robin.
     看起来是顺序的,其实不然,除了保存log buffer刷新到磁盘的log block,还保存了一些其他信息,这些信息占:2KB,即redo log file 的前2KB不保存log block的信息。
 
2KB的信息:保存 4 * 512字节的 块。
 
名称
大小(字节)
log file header
512
checkpoint1
512
512
checkpoint2
512
 
 
 
 
 
 
上述信息只在log group的第一个redo log file里存储,其余file留空,这也就是说 写入不是顺序的!如下图:
 
 
4.重做日志的格式
 
 
5.LSN
LSN : Log Sequence Number的缩写,代表日志序列号,单位:字节。在innodb存储引擎中占有8字节,单调递增。
LSN : 表示的含义
  1. 重做日志写入的总量
  2. checkpoint的位置
  3. 页的版本
LSN 表示事务写入重做日志的字节总量。例如,当前重做日志的LSN是1000,事务T1写入了100字节的重做日志,LSN就变成1100,又有事务T2写入200字节的重做日志,那么LSN变成:1300.
 
LSN不仅记录在重做日志中,还记录在页中。每个页的开头部有一个FIL_PAGE_LNS,记录该页的LSN。
页中的LSN表示:该页最后刷新时LSN的大小。
重做日志记录的是每个页的物理更改日志,因此页中的LSN用来判断是否需要进行恢复操作。例如:页的LSN为:10000,数据库启动时,写入重做日志的LSN:13000,表明该事务已经提交,数据库需要恢复;重做日志中的LSN小于页中的LSN,不需要进行重做,因为页中的LSN表示已经刷新到该位置。
 
通过:SHOW ENGINE INNODB STATUS\G来查看LSN的情况
---
LOG
---
Log sequence number 47324552     ----------------->表示当前的LSN
Log flushed up to   47324552     ----------------->表示刷新到重做日志的LSN
Pages flushed up to 47324552     ----------------->表示刷新到磁盘的LSN
Last checkpoint at  47324552
Max checkpoint age    80826164
Checkpoint age target 78300347
....
 
上述的3个值,生产环境中可能是不同的:因为一个事务从重做日志缓冲刷新到重做日志文件,并不只是在事务提交时发生,每秒都会有重做日志缓冲刷新到重做日志文件的操作。
 
6.恢复
 
InnoDB存储引擎在启动时,不管上次数据库是否正常关闭,都会尝试进行恢复。重做日志是物理日志,恢复时比较快。
checkpoint 表示已经刷新到磁盘上的LSN。
 
例子:redo log file 记录的LSN:13000,刷新到磁盘上的LSN:10000,数据库在10000处宕机,恢复时,只需恢复10000~13000的部分。
 
 
--完结
 
posted @ 2017-03-14 17:44  缥缈之旅  阅读(5380)  评论(4编辑  收藏  举报