一、 序言
针对突然宕机的问题:MySql不会自动继续执行,不会自动直接回滚,但是可以人工手动选择继续执行或者直接回滚,依据是事务日志。
事务开启时,事务中的操作,都会先写入存储引擎的日志缓冲中,在事务提交之前,这些缓冲的日志都需要提前刷新到磁盘上持久化,这就是人们口中常说的“日志先行”(Write-Ahead Logging)
为了最大程度避免数据写入时io瓶颈带来的性能问题,MySQL采用了这样一种缓存机制:当query修改数据库内数据时,InnoDB先将该数据从磁盘读取到内存中,修改内存中的数据拷贝,并将该修改行为持久化到磁盘上的事务日志(先写redo log buffer,再定期批量写入),而不是每次都直接将修改过的数据记录到硬盘内,等事务日志持久化完成之后,内存中的脏数据可以慢慢刷回磁盘,称之为Write-Ahead Logging。事务日志采用的是追加写入,顺序io会带来更好的性能优势。
innodb事务日志包括redo log和undo log。redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作。
二、undo log 和 redo log
-
概念
在数据库系统中,事务的原子性和持久性是由事务日志(transaction log)保证的,在实现时也就是上面提到的两种日志,前者用于对事务的影响进行撤销,后者在错误处理时对已经提交的事务进行重做,它们能保证两点:
1、发生错误或者需要回滚的事务能够成功回滚(原子性);
2、在事务提交后,数据没来得及写会磁盘就宕机时,在下次重新启动后能够成功恢复数据(持久性);
在数据库中,这两种日志经常都是一起工作的,我们可以将它们整体看做一条事务日志,其中包含了事务的 ID、修改的行元素以及修改前后的值。
-
redo log (重做日志)——保障的是事务的持久性和一致性
为了避免脏数据刷回磁盘过程中,掉电或系统故障带来的数据丢失问题,InnoDB采用事务日志(redo log)来解决该问题。
在事务 提交之后,数据没有来得及 写入 到 磁盘 的时候,mysql 重启 就会执行 redo log 重做日志
redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置)。
-
undo log (回滚日志)——保障了事务的原子性,主要为事务的回滚服务
执行过程中发生异常,错误,手动回滚,都是执行的undo日志。事务执行完了 mysql 是不会 再去执行 事务回滚日志。
undo用来回滚行记录到某个版本。undo log一般是逻辑日志,根据每行记录进行记录。
-
默认 存放位置(可以修改mysql.ini 进行配置)
redo log => ib_logfile*
undo log => ibdata* -
几个相关命令
查看事务日志 :show engine innodb status\G;
查看日志文件设置状态:show variables like ‘innodb_%’;
三、redo log和undo log的过程分析
eg : 假设有2个数值,分别为A和B,值为1,2
1 start transaction;
2 记录 A=1 到undo log;
3 update A = 3;
4 记录 A=3 到redo log;
5 记录 B=2 到undo log;
6 update B = 4;
7 记录B = 4 到redo log;
8 将redo log刷新到磁盘
9 commit
在1-8的任意一步系统宕机,事务未提交,该事务就不会对磁盘上的数据做任何影响.
如果在8-9之间宕机,恢复之后可以选择回滚,也可以选择继续完成事务提交,因为此时redo log已经持久化若在9之后系统宕机,内存映射中变更的数据还来不及刷回磁盘,那么系统恢复之后,可以根据redo log把数据刷回磁盘
四、undo log工作原理
在数据修改的时候,不仅记录了redo,还记录了相对应的undo,如果因为某些原因导致事务失败或回滚了,可以借助该undo进行回滚。
想要保证事务的原子性,就需要在异常发生时,对已经执行的操作进行回滚,而在 MySQL 中,恢复机制是通过回滚日志(undo log)实现的,所有事务进行的修改都会先记录到这个回滚日志中,然后在对数据库中的对应行进行写入。
注意:系统发生崩溃、数据库进程直接被杀死后,当用户再次启动数据库进程时,还能够立刻通过查询回滚日志将之前未完成的事务进行回滚,这也就需要回滚日志必须先于数据持久化到磁盘上,是我们需要先写日志后写数据库的主要原因。
在日志文件中:在事务中使用的每一条 INSERT 都对应了一条 DELETE,每一条 UPDATE 也都对应一条相反的 UPDATE 语句。
如上所示 可以认为当insert一条记录时,undo log中会记录一条对应的delete记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录。当执行rollback时,就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
五、redo log工作原理
redo log包括两部分:一是内存中的日志缓冲(redo log buffer),该部分日志是易失性的;二是磁盘上的重做日志文件(redo log file),该部分日志是持久的。
Redo log记录的是新数据的备份。在事务提交前,只需要将Redo log持久化,不需要将数据数据持久化。当数据库系统崩溃时,虽然数据没有持久化,但是Redo log已经持久化了。在系统从崩溃中恢复时,可以根据Redo log中的内容,将所有的数据恢复到最新的状态。
如上图所示:当我们在一个事务中尝试对数据进行写时,它会先将数据从磁盘读入内存,并更新内存中缓存的数据,然后生成一条重做日志并写入重做日志缓存,当事务真正提交时,MySQL 会将重做日志缓存中的内容刷新到重做日志文件,再将内存中的数据更新到磁盘上,图中的第 4、5 步就是在事务提交时执行的。
六、事务日志流程
-
MySQL的checkpoint:
checkpoint,即检查点。在undolog中写入检查点,表示在checkpoint前的事务都已经完成commit或者rollback了,也就是检查点前面的事务已经不存在数据一致性的问题了
-
mysql事务日志
Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfile里面(去mysql数据目录下看下)。Innodb还有另外一个日志Undo log,但Undo log是存放在共享表空间里面的(ibdata*文件,存储的是check point日志序列号)。
-
流程
如上图所示,Innodb的一条事务日志共经历4个阶段:1、创建阶段:事务创建一条日志; 2、日志刷盘:日志写入到磁盘上的日志文件; (ib_logfile里面) 3、数据刷盘:日志对应的脏页数据写入到磁盘上的数据文件; 4、写CKP:日志被当作Checkpoint写入日志文件;(ib_data里面
七、innodb_flush_log_at_trx_commit 参数解析
-
概念
innodb_flush_log_at_trx_commit 用来配置flush log到磁盘的时机。具体就是从log buffer写到log file,并写入到磁盘上的时机。
-
操作命令
-- 查看日志文件设置状态: show variables like 'innodb_%'; -- 更改: set @@global.innodb_flush_log_at_trx_commit = 0; -- 0,1,2 show variables like 'innodb_flush_log_at_trx_commit';
-
对比
0:(延迟写): log_buff --每隔1秒–> log_file —实时—> disk
1:(实时写,实时刷): log_buff —>实时—> log_file —实时—> disk–>系统默认
2:(实时写,延迟刷): log_buff —实时—> log_file --每隔1秒–> disk
-
性能测试对比
性能的检测办法:
设置innodb_flush_log_at_trx_commit 不同的值,然后对比 所用的时间
-
数据问题对比
因为在实际过程中很难去模拟实际的断点故障的情况,但是你可以尝试通过终止MySQL服务来测试;数据的插入速度是很快的(大量数据除外),为了方便测试这里可以对于数据插入之后睡眠一下,然后再去终止MySQL服务;就可以模拟情况;过程需要自己返回测试过程 cmd 运行程序 然后 执行数据的过程中终止MySQL服务
具体三个参数的优缺点,在上一篇文章,已经做了详细说明,这里不在赘述。
事务不会自动回滚
特别注意:在程序中使用了事务之后,如果在事务提交之前程序发生了异常,事务是不会自动回滚的。因此在程序中使用事务时,一般用try catch 捕获异常,来实现手动回滚。
总结两点
1、在事务操作过程中***没有commit***,但是服务器异常终止,如果服务器重启会执行undo log 日志,把数据还原为初始状态。
2、事务在操作过程中commit,但是还没来得及把数据写入到磁盘中,服务器异常终止,此时就由redo log决定了。
redo log 由两部分组成:
一个是内存中的日志缓冲(redo log buffer),该部分日志是易失性的;
二是磁盘上的重做日志文件(redo log file),该部分日志是持久的
此时要 配合这个参数 innodb_flush_log_at_trx_commit(如下图):