mysqliblogfile_Mysql事务日志(Ib_logfile)

mysql的innodb中事务日志ib_logfile(0/1)

概念&＃xff1a;

事务日志或称redo日志&＃xff0c;在mysql中默认以ib_logfile0,ib_logfile1名称存在,可以手工修改参数&＃xff0c;调节开启几组日志来服务于当前mysql数据库,mysql采用顺序&＃xff0c;循环写方式&＃xff0c;每开启一个事务时&＃xff0c;会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位置或叫做偏移量);

这个系列文件个数由参数innodb_log_files_in_group控制&＃xff0c;若设置为4&＃xff0c;则命名为ib_logfile0~3。

这些文件的写入是顺序、循环写的&＃xff0c;logfile0写完从logfile1继续&＃xff0c;logfile3写完则logfile0继续。

作用:

在系统崩溃重启时&＃xff0c;作事务重做&＃xff1b;在系统正常时&＃xff0c;每次checkpoint时间点&＃xff0c;会将之前写入事务应用到数据文件中。

Ib_logfile的checkpoint field

实际上不仅要记录checkpoint做到哪儿(LOG_CHECKPOINT_LSN)&＃xff0c;还要记录用到了哪个位置(LOG_CHECKPOINT_OFFSET)等其他信息。所以在ib_logfile0的头部预留了空间&＃xff0c;用于记录这些信息。

因此即使使用后面的logfile&＃xff0c;每次checkpoint完成后&＃xff0c;ib_logfile0都是要更新的。同时你会发现所谓的顺序写盘&＃xff0c;也并不是绝对的

相关的一些数字

a) InnoDB留了两个checkpoint filed&＃xff0c;按照注释的解释&＃xff0c;目的是为了能够“write alternately”

b) 每个checkpint field需要的大小空间为304字节。(相关定义在log0log.h)

c) 第一个checkpoint的起始位置在ib_logfile0的第512字节(OS_FILE_LOG_BLOCK_SIZE)处&＃xff1b;

d) 第二个在1536 (3 * OS_FILE_LOG_BLOCK_SIZE)字节处。

特点&＃xff1a;

redo log只是记录所有innodb表数据的变化。

redo log只是记录正在执行中的dml以及ddl语句。

redo log可以作为异常down机或者介质故障后的数据恢复使用

引入一个问题&＃xff1a;

在m/s环境中,innodb写完ib_logfile后,服务异常关闭&＃xff0c;会不会主库能用ib_logfile恢复数据&＃xff0c;而

binlog没写导致从库同步时少了这个事务&＃xff1f;从而导致主从不一致;

redo日志写入方式&＃xff1a;1.ib_logfile写入当前事务更新数据&＃xff0c;并标上事务准备trx_prepare2.写入bin-log3.ib_logfile当前事务提交提交trx_commit

恢复方式:

如果ib_logfile已经写入事务准备,那么在恢复过程中&＃xff0c;会依据bin-log中该事务是否存在恢复数据。

假设:1)结束后异常,因没有写入bin-log&＃xff0c;从库不会同步这个事务&＃xff0c;主库上&＃xff0c;重启时&＃xff0c;在恢复日志中这个事务没有commit&＃xff0c;即rollback这个事务.2)结束后异常&＃xff0c;这会bin-log已经写入&＃xff0c;从库会同步这个事务。主库依据恢复日志和bin-log&＃xff0c;也正常恢复此事务

综上描述:

bin-log写入完成&＃xff0c;主从会正常完成事务&＃xff1b;bin-log没有写入&＃xff0c;主从库rollback事务;不会出现主从库不一致问题.

相关参数(全局&静态):

innodb_log_buffer_size

innodb_log_file_size

innodb_log_files_in_group

innodb_log_group_home_dir

innodb_flush_log_at_trx_commit

innodb_log_buffer_size:

事务日志缓存区,可设置1M~8M,默认8M,延迟事务日志写入磁盘,把事务日志缓存区想象形如"漏斗"状,会不停向磁盘记录缓存的日志记录,而何时写入通过参数innodb_flush_log_at_trx_commit控制,稍后解释,启用大的事务日志缓存,可以将完整运行大事务日志&＃xff0c;

暂时存放在事务缓存区中,不必(事务提交前)写入磁盘保存,同时也起到节约磁盘空间占用;

innodb_log_file_size:控制事务日志ib_logfile的大小,范围5MB~4G&＃xff1b;所有事务日志ib_logfile0&＃43;ib_logfile1&＃43;..累加大小不能超过4G&＃xff0c;事务日志大&＃xff0c;checkpoint会少,节省磁盘IO&＃xff0c;但是大的事务日志意味着数据库crash时&＃xff0c;恢复起来较慢.

引入问题:修改该参数大小&＃xff0c;导致ib_logfile文件的大小和之前存在的文件大小不匹配

解决方式&＃xff1a;在干净关闭数据库情况下&＃xff0c;删除ib_logfile&＃xff0c;而后重启数据库&＃xff0c;会自行创建该文件;

innodb_log_files_in_group:DB中设置几组事务日志&＃xff0c;默认是2&＃xff1b;

innodb_log_group_home_dir:事务日志存放目录&＃xff0c;不设置&＃xff0c;ib_logfile0...存在在数据文件目录下

innodb_flush_log_at_trx_commit&＃xff1a;控制事务日志何时写盘和刷盘&＃xff0c;安全递增&＃xff1a;0,2,1事务缓存区:log_buffer;0:每秒一次事务缓存区刷新到文件系统&＃xff0c;同时文件系统到磁盘同步&＃xff0c;但是事务提交时&＃xff0c;不会触发log_buffer到文件系统同步&＃xff1b;2:每次事务提交时,会把事务缓存区日志刷新到文件系统中去&＃xff0c;且每秒文件系统到磁盘同步;1:每次事务提交时刷新到磁盘&＃xff0c;最安全;

适用环境:0:磁盘IO能力有限,安全方便较差,无复制或复制延迟可以接受&＃xff0c;如日志性业务&＃xff0c;mysql损坏丢失1s事务数据;2:数据安全性有要求&＃xff0c;可以丢失一点事务日志&＃xff0c;复制延迟也可以接受&＃xff0c;OS损坏时才可能丢失数据;1:数据安全性要求非常高&＃xff0c;且磁盘IO能力足够支持业务&＃xff0c;如充值消费&＃xff0c;敏感业务;

引入ib_logfile的写入策略

1、基本概念

a)、ib_logfile文件个数由innodb_log_files_in_group配置决定&＃xff0c;若为2&＃xff0c;则在datadir目录下有两个文件&＃xff0c;命令从0开始&＃xff0c;分别为ib_logfile0和ib_logfile.

b)、文件为顺序写入&＃xff0c;当达到最后一个文件末尾时&＃xff0c;会从第一个文件开始顺序复用。

c)、lsn: Log Sequence Number&＃xff0c;是一个递增的整数。 Ib_logfile中的每次写入操作都包含至少1个log&＃xff0c;每个log都带有一个lsn。在内存page修复过程中&＃xff0c;只有大于page_lsn的log才会被使用。

d)、lsn的保存在全局变量log_sys中。递增数值等于每个log的实际内容长度。即如果新增的一个log长度是len&＃xff0c;则log_sys->lsn &＃43;&＃61; len.

e)、ib_logfile每次写入以512(OS_FILE_LOG_BLOCK_SIZE)字节为单位。实际写入函数 log_group_write_buf (log/log0log.c)

f)、每次写盘后是否flush&＃xff0c;由参数innodb_flush_log_at_trx_commit控制。

2、log_sys介绍

log_sys是一个全局内存结构。以下说明几个成员的意义。

lsn

表示已经分配的最后一个lsn的值。

written_to_all_lsn

n表示实际已经写盘的lsn。需要这个值是因为并非每次生成log后就写盘。

flushed_to_disk_lsn

表示刷到磁盘的lsn。需要这个值是因为并非每次写盘后就flush。

buf

待写入的内容保存在buf中

buf_size

buf的大小。由配置中innodb_log_buffer_size决定&＃xff0c;实际大小为innodb_log_buffer_size /16k * 16k。

buf_next_to_write

buf中下一个要写入磁盘的位置

buf_free

buf中实际内容的最后位置。当buf_free> buf_next_to_write时&＃xff0c;说明内存中还有数据未写盘。

3、相关更新

用一个简单的更新语句来说明log_sys以及ib_logfile的更新内容的过程。假设我们的更新只涉及到非索引的固定长度字段。

a) 在bufferpool中写入undo log。 对于一个单一的语句&＃xff0c;需要先创建一个undolog头。

b) 在bufferpool中写入undo log的实际内容。

c) 在log_sys->buf中写入buffer page的更新内容。此处保存了更新的完整信息。

d) 在log_sys->buf中写入启动事务(trx_prepare)的日志

e) 将c、d更新的log内容写入ib_logfile中。

f) 在log_sys->buf中写入事务结束(trx_commit)的日志

g) 将f步骤的log内容写入ib_logfile中。

4、说明

a) 完成上述所有操作时&＃xff0c;数据文件还没有更新。

b) 每次写入log_sys->buf时同时更新lsn和buf_free。 每次写ib_logfile时同时更新written_to_all_lsn和buf_next_to_write&＃xff1b;

c) 每次写ib_logfile时以512字节为对齐&＃xff0c;如需写入600字节&＃xff0c;则实际写入1k。写到最后一个文件末尾则从第一个文件重复使用。

d) 从上述流程看到&＃xff0c;在a&＃xff5e;d过程中若出现异常关闭&＃xff0c;由于没有写入到磁盘中&＃xff0c;因此整个事务放弃&＃xff1b;若在e刚完成时出现异常关闭&＃xff0c;虽然事务内容已经写盘&＃xff0c;但没有提交。在重启恢复的时候&＃xff0c;发现这个事务还没有提交&＃xff0c;逻辑上整个事务放弃。 (重启日志中会有Found 1 prepared transaction(s) in InnoDB字样)。在g完成后出现异常关闭&＃xff0c;则能够在重启恢复中正常提交。

在e和f之间会写mysql的bin-log&＃xff0c;若bin-log写完前异常关闭&＃xff0c;事务无效&＃xff0c;bin-log写入成功后&＃xff0c;则异常重启后能够根据bin-log恢复事务的修改。

e) 若涉及到索引更新&＃xff0c;在步骤c之后会增加索引更新的log。由于索引可能有merge过程&＃xff0c;因此在merge过程中会另外增加写入一个log。但事务完全提交仍在步骤g中。索引的更新由于已经写盘&＃xff0c;并不会因此丢失。

参考文档&＃xff1a;