MySQL重做日志相关

 

 

Ⅰ、事务的实现

这里我们先抛出答案,通过答案再展开分析

特性 实现
A(原子性) redo
C(一致性) undo
I(隔离性) lock
D(持久性) redo/undo

本节针对redo展开分析

Ⅱ、redo详解

2.1 redo log buffer

  • redo就是我们常说的重做日志,用来实现持久性
  • mysql目录下两个ib_logfile文件,就是重做日志文件,在ssd场景下至少设置为4G
  • redo log里面记录的是每个page修改操作的物理逻辑日志(不是完全的二进制的差异值,比如一个sql修改了一千万行,一千万个page被修改了,那记录的是1000w page的变化,而不是sql语句)

redo由redo log buffer和redo log file组成,重做日志先写入一块内存,再定期刷新到磁盘

先看下redo log buffer

它由很多个log block组成,每个log block 512个字节,不需要doublewrite

innodb_log_buffer_size    8M即可,不需要太大,一秒钟写满8M不太可能

redo log刷盘的条件

①master thread    每秒从内存刷到磁盘
  5.6版本后,增加innodb_flush_log_at_timeout参数,可以设置刷新间隔,默认为1,调大一点可减少io,提升性能,但不建议

②redo log buffer  使用大于1/2也会刷 ③事务提交时进行刷新,即使上面两个条件不满足(事务持久性的要求) innodb_flush_log_at_trx_commit={0|1|2},默认为1,事务提交时将redo log buffer写到磁盘(即使上面两个条件不满足,这样crash了就还可以通过redo恢复),只有是1的时候innodb才能真正达到持久性的标准 事务对page做了修改,提交的时候并不需要保证赃页刷到磁盘,只需要保证将对应修改的日志刷过去就可以了 0表示交给master thread每秒刷新,事务提交不将redo log buffer刷到磁盘,最多会丢失1s的事务 2表示事务提交时仅将redo log buffer写到操作系统缓存,所以mysql重启,只要操作系统没重启,那数据还是在的额

2.2 redo log file

先弄个图看看redo buffer刷盘吧

每个ib_logfile都分为很多个512bits的块,最前头2k是留出来写checkpoint的,通过对比两个cp可知哪个是最新的,cp1和cp2轮询写确保cp不会坏掉,一个坏了也没事,即使用小的cp顶多就是恢复的时候多一点时间,没有oracle的归档

优点: 这样做的好处是不需要归档,少了IO操作
缺点: 如果redo_log_file太小则可能需要等待,因为当要覆盖log_file中的log_block时,如果该log_block中的脏页还没有进行刷新的话,则需要等待这个脏页进行刷新
所以需要把redo log file设置的尽可能的大

redo日志分类

物理日志:记录整个page的变化(diff)

逻辑日志:Like SQL语句

物理逻辑日志:根据page进行记录,内容逻辑

redo log file与redo log buffer内容一致

+---------------+----------+---------+---------------+
| redo_log_type | space no | page no | redo log body |
+---------------+----------+---------+---------------+
#  redo log 类型 表空间号 页号 redo log 内容 MLOG_REC_INSERT +------+--------+------+---------+------------+-------+---------+-----------+----------+ | type | space | page | cur_rec | len & | info | origin | mis_match | rec body | | | no | no | _offset | extra_info | _bits | _offset | _index | | +------+--------+------+---------+------------+-------+---------+-----------+----------+ MLOG_REC_DELETE +------+----------+---------+--------+ | type | space no | page no | offset | +------+----------+---------+--------+ rec body根据page的变化来记录,而不是根据操作SQL来记录,所以偏物理日志 因为还记录了redo log body,一个具体操作,所以又叫逻辑 每种不同类型的redo log的内在格式可能长得不一样

相关参数

innodb_log_file_size 单个redo文件大小(推荐8G,官方推荐等于bp)
  之前不建议调大因为有bug,如果调大,恢复速度会很慢O(N^2) 5.5版本的redo文件总大小(num * size)最大只能4G 5.6之后限制未512G,调大后唯一的问题就是恢复的内容变多了 5.6之后,正常关闭MySQL,然后调整该值,会自动调整文件大小 innodb_log_files_in_group innodb_log_group_home_dir 和数据文件分开,选择更快的磁盘
 
分类:  MySQL

Ⅰ、事务的实现

这里我们先抛出答案,通过答案再展开分析

特性 实现
A(原子性) redo
C(一致性) undo
I(隔离性) lock
D(持久性) redo/undo

本节针对redo展开分析

Ⅱ、redo详解

2.1 redo log buffer

  • redo就是我们常说的重做日志,用来实现持久性
  • mysql目录下两个ib_logfile文件,就是重做日志文件,在ssd场景下至少设置为4G
  • redo log里面记录的是每个page修改操作的物理逻辑日志(不是完全的二进制的差异值,比如一个sql修改了一千万行,一千万个page被修改了,那记录的是1000w page的变化,而不是sql语句)

redo由redo log buffer和redo log file组成,重做日志先写入一块内存,再定期刷新到磁盘

先看下redo log buffer

它由很多个log block组成,每个log block 512个字节,不需要doublewrite

innodb_log_buffer_size    8M即可,不需要太大,一秒钟写满8M不太可能

redo log刷盘的条件

①master thread    每秒从内存刷到磁盘
  5.6版本后,增加innodb_flush_log_at_timeout参数,可以设置刷新间隔,默认为1,调大一点可减少io,提升性能,但不建议

②redo log buffer  使用大于1/2也会刷 ③事务提交时进行刷新,即使上面两个条件不满足(事务持久性的要求) innodb_flush_log_at_trx_commit={0|1|2},默认为1,事务提交时将redo log buffer写到磁盘(即使上面两个条件不满足,这样crash了就还可以通过redo恢复),只有是1的时候innodb才能真正达到持久性的标准 事务对page做了修改,提交的时候并不需要保证赃页刷到磁盘,只需要保证将对应修改的日志刷过去就可以了 0表示交给master thread每秒刷新,事务提交不将redo log buffer刷到磁盘,最多会丢失1s的事务 2表示事务提交时仅将redo log buffer写到操作系统缓存,所以mysql重启,只要操作系统没重启,那数据还是在的额

2.2 redo log file

先弄个图看看redo buffer刷盘吧

每个ib_logfile都分为很多个512bits的块,最前头2k是留出来写checkpoint的,通过对比两个cp可知哪个是最新的,cp1和cp2轮询写确保cp不会坏掉,一个坏了也没事,即使用小的cp顶多就是恢复的时候多一点时间,没有oracle的归档

优点: 这样做的好处是不需要归档,少了IO操作
缺点: 如果redo_log_file太小则可能需要等待,因为当要覆盖log_file中的log_block时,如果该log_block中的脏页还没有进行刷新的话,则需要等待这个脏页进行刷新
所以需要把redo log file设置的尽可能的大

redo日志分类

物理日志:记录整个page的变化(diff)

逻辑日志:Like SQL语句

物理逻辑日志:根据page进行记录,内容逻辑

redo log file与redo log buffer内容一致

+---------------+----------+---------+---------------+
| redo_log_type | space no | page no | redo log body |
+---------------+----------+---------+---------------+
#  redo log 类型 表空间号 页号 redo log 内容 MLOG_REC_INSERT +------+--------+------+---------+------------+-------+---------+-----------+----------+ | type | space | page | cur_rec | len & | info | origin | mis_match | rec body | | | no | no | _offset | extra_info | _bits | _offset | _index | | +------+--------+------+---------+------------+-------+---------+-----------+----------+ MLOG_REC_DELETE +------+----------+---------+--------+ | type | space no | page no | offset | +------+----------+---------+--------+ rec body根据page的变化来记录,而不是根据操作SQL来记录,所以偏物理日志 因为还记录了redo log body,一个具体操作,所以又叫逻辑 每种不同类型的redo log的内在格式可能长得不一样

相关参数

innodb_log_file_size 单个redo文件大小(推荐8G,官方推荐等于bp)
  之前不建议调大因为有bug,如果调大,恢复速度会很慢O(N^2) 5.5版本的redo文件总大小(num * size)最大只能4G 5.6之后限制未512G,调大后唯一的问题就是恢复的内容变多了 5.6之后,正常关闭MySQL,然后调整该值,会自动调整文件大小 innodb_log_files_in_group innodb_log_group_home_dir 和数据文件分开,选择更快的磁盘

猜你喜欢

转载自www.cnblogs.com/DataArt/p/10236644.html