再次详解MySQL事务日志(redo log和undo log)的详细分析
前言
innodb事务日志包括redo log和undo log。redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作。
undo log不是redo log的逆向进程,其实它们都算是用来恢复的日志:
1.redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置)。
2.undo用来回滚行记录到某个版本。undo log通常为逻辑日志,根据每行记录进行记录。
1.redo log
1.1 redo log和二进制日志的区分
二进制日志相关内容,参考:MariaDB/MySQL的二进制日志。
redo log不是二进制日志。虽然二进制日志中也记录了innodb表的很多操作,也能实现重做的功能,但是它们之间有很大区分。
- 二进制日志是在存储引擎的上层产生的,不论是甚么存储引擎,对数据库进行了修改都会产生二进制日志。而redo log是innodb层产生的,只记录该存储引擎中表的修改。并且二进制日志先于redo log被记录。具体的见后文group commit小结。
- 二进制日志记录操作的方法是逻辑性的语句。即使它是基于行格式的记录方式,其本质也或者逻辑的SQL设置,如该行记录的每列的值是多少。而redo log是在物理格式上的日志,它记录的是数据库中每一个页的修改。
- 二进制日志只在每次事务提交的时候一次性写入缓存中的日志"文件"(对非事务表的操作,则是每次履行语句成功后就直接写入)。而redo log在数据准备修改前写入缓存中的redo log中,然后才对缓存中的数据履行修改操作;而且保证在发失事务提交指令时,先向缓存中的redo log写入日志,写入完成后才履行提交动作。
- 由于二进制日志只在提交的时候一次性写入,所以二进制日志中的记录方式和提交顺序有关,且一次提交对应一次记录。而redo log中是记录的物理页的修改,redo log文件中同一个事务可能屡次记录,最后一个提交的事务记录会覆盖所有未提交的事务记录。例如事务T1,可能在redo log中记录了 T1⑴,T1⑵,T1⑶,T1* 共4个操作,其中 T1* 表示最后提交时的日志记录,所以对应的数据页终究状态是 T1* 对应的操作结果。而且redo log是并发写入的,区别事务之间的区别版本的记录会穿插写入到redo log文件中,例如可能redo log的记录方式以下: T1⑴,T1⑵,T2⑴,T2⑵,T2*,T1⑶,T1* 。
- 事务日志记录的是物理页的情况,它具有幂等性,因此记录日志的方式极为简练。幂等性的意思是屡次操作前后状态是一样的,例如新插入一行后又删除该行,前后状态没有变化。而二进制日志记录的是所有影响数据的操作,记录的内容较多。例如插入一行记录一次,删除该行又记录一次。
1.2 redo log的基本概念
redo log包括两部份:一是内存中的日志缓冲(redo log buffer),该部份日志是易失性的;二是磁盘上的重做日志文件(redo log file),该部份日志是持久的。
在概念上,innodb通过force log at commit机制实现事务的持久性,即在事务提交的时候,一定要先将该事务的所有事务日志写入到磁盘上的redo log file和undo log file中进行持久化。
为了确保每第二天志都能写入到事务日志文件中,在每次将log buffer中的日志写入日志文件的进程中都会调用一次操作系统的fsync操作(即fsync()系统调用)。由于MariaDB/MySQL是工作在用户空间的,MariaDB/MySQL的log buffer处于用户空间的内存中。要写入到磁盘上的log file中(redo:ib_logfileN文件,undo:share tablespace或.ibd文件),中间还要经过操作系统内核空间的os buffer,调用fsync()的作用就是将OS buffer中的日志刷到磁盘上的log file中。
也就是说,从redo log buffer写日志到磁盘的redo log file中,进程以下:
在此处需要注意一点,一般所说的log file其实不是磁盘上的物理日志文件,而是操作系统缓存中的log file,官方手册上的意思也是如此(例如:With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second)。但说实话,这不太好理解,既然都称为file了,应当已属于物理文件了。所以在本文后续内容中都以os buffer或file system buffer来表示官方手册中所说的Log file,然后log file则表示磁盘上的物理日志文件,即log file on disk。
另外,之所以要经过一层os buffer,是由于open日志文件的时候,open没有使用O_DIRECT标志位,该标志位意味着绕过操作系统层的os buffer,IO直写到底层存储装备。不使用该标志位意味着将日志进行缓冲,缓冲到了一定容量,或显式fsync()才会将缓冲中的刷到存储装备。使用该标志位意味着每次都要发起系统调用。比如写abcde,不使用o_direct将只发起一次系统调用,使用o_object将发起5次系统调用。
MySQL支持用户自定义在commit时怎么将log buffer中的日志刷log file中。这类控制通过变量innodb_flush_log_at_trx_commit的值来决定。该变量有3种值:0、1、2,默许为1。但注意,这个变量只是控制commit动作会不会刷新log buffer到磁盘。
- 当设置为1的时候,事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这类方式即便系统崩溃也不会丢失任何数据,但是由于每次提交都写入磁盘,IO的性能较差。
- 当设置为0的时候,事务提交时不会将log buffer中日志写入到os buffer,而是每秒写入os buffer并调用fsync()写入到log file on disk中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的,当系统崩溃,会丢失1秒钟的数据。
- 当设置为2的时候,每次提交都仅写入到os buffer,然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。
注意,有一个变量innodb_flush_log_at_timeout的值为1秒,该变量表示的是刷日志的频率,很多人误以为是控制innodb_flush_log_at_trx_commit值为0和2时的1秒频率,实际上并不是如此。测试时将频率设置为5和设置为1,当innodb_flush_log_at_trx_commit设置为0和2的时候性能基本都是不变的。关于这个频率是控制甚么的,在后面的"刷日志到磁盘的规则"中会说。
在主从复制结构中,要保证事务的持久性和一致性,需要对日志相关变量设置为以下:
- 如果启用了二进制日志,则设置sync_binlog=1,即每提交一次事务同步写到磁盘中。
- 总是设置innodb_flush_log_at_trx_commit=1,即每提交一次事务都写到磁盘中。
上述两项变量的设置保证了:每次提交事务都写入二进制日志和事务日志,并在提交时将它们刷新到磁盘中。
选择刷日志的时间会严重影响数据修改时的性能,特别是刷到磁盘的进程。下例就测试了innodb_flush_log_at_trx_commit分别为0、1、2时的差距。
drop table if exists test_flush_log;
create table test_flush_log(id int,name char(50))engine=innodb;
#创建插入指定行数的记录到测试表中的存储进程
drop procedure if exists proc;
delimiter $$
create procedure proc(i int)
begin
declare s int default 1;
declare c char(50) default repeat(‘a’,50);
while s<=i do
start transaction;
insert into test_flush_log values(null,c);
commit;
set s=s+1;
end while;
end$$
delimiter ;
当前环境下,innodb_flush_log_at_trx_commit的值为1,即每次提交都刷日志到磁盘。测试此时插入10W条记录的时间。
Query OK, 0 rows affected (15.48 sec)
结果是15.48秒。
再测试值为2的时候,即每次提交都刷新到os buffer,但每秒才刷入磁盘中。
mysql> truncate test_flush_log;
mysql> call proc(100000);
Query OK, 0 rows affected (3.41 sec)
结果插入时间大减,只需3.41秒。
最后测试值为0的时候,即每秒才刷到os buffer和磁盘。
mysql> truncate test_flush_log;
mysql> call proc(100000);
Query OK, 0 rows affected (2.10 sec)
结果只有2.10秒。
最后可以发现,其实值为2和0的时候,它们的差距其实不太大,但2却比0要安全的多。它们都是每秒从os buffer刷到磁盘,它们之间的时间差体现在log buffer刷到os buffer上。由于将log buffer中的日志刷新到os buffer只是内存数据的转移,并没有太大的开消,所以每次提交和每秒刷入差距其实不大。可以测试插入更多的数据来比较,以下是插入100W行数据的情况。从结果可见,值为2和0的时候差距其实不大,但值为1的性能却差太多。
虽然设置为0和2可以大幅度提升插入性能,但是在故障的时候可能会丢失1秒钟数据,这1秒钟极可能有大量的数据,从上面的测试结果看,100W条记录也只消耗了20多秒,1秒钟大约有4W⑸W条数据,虽然上述插入的数据简单,但却说明了数据丢失的大量性。更好的插入数据的做法是将值设置为1,然后修改存储进程,将每次循环都提交修改成只提交一次,这样既能保证数据的一致性,也能提升性能,修改以下:
delimiter $$
create procedure proc(i int)
begin
declare s int default 1;
declare c char(50) default repeat(‘a’,50);
start transaction;
while s<=i DO
insert into test_flush_log values(null,c);
set s=s+1;
end while;
commit;
end$$
delimiter ;
测试值为1时的情况。
mysql> truncate test_flush_log;
mysql> call proc(1000000);
Query OK, 0 rows affected (11.26 sec)
1.3 日志块(log block)
innodb存储引擎中,redo log以块为单位进行存储的,每一个块占512字节,这称为redo log block。所以不论是log buffer中或者os buffer中和redo log file on disk中,都是这样以512字节的块存储的。
每一个redo log block由3部份组成:日志块头、日志块尾和日志主体。其中日志块头占用12字节,日志块尾占用8字节,所以每一个redo log block的日志主体部份只有512⑴2⑻=492字节。
由于redo log记录的是数据页的变化,当一个数据页产生的变化需要使用超过492字节()的redo log来记录,那末就会使用多个redo log block来记录该数据页的变化。
日志块头包括4部份:
- Ÿ log_block_hdr_no:(4字节)该日志块在redo log buffer中的位置ID。
- Ÿ log_block_hdr_data_len:(2字节)该log block中已记录的log大小。写满该log block时为0x200,表示512字节。
- Ÿ log_block_first_rec_group:(2字节)该log block中第一个log的开始偏移位置。
- Ÿ lock_block_checkpoint_no:(4字节)写入检查点信息的位置。
关于log block块头的第三部份log_block_first_rec_group,由于有时候一个数据页产生的日志量超越了一个日志块,这是需要用多个日志块来记录该页的相关日志。例如,某一数据页产生了552字节的日志量,那末需要占用两个日志块,第一个日志块占用492字节,第二个日志块需要占用60个字节,那末对第二个日志块来讲,它的第一个log的开始位置就是73字节(60+12)。如果该部份的值和log_block_hdr_data_len相等,则说明该log block中没有新开始的日志块,即表示该日志块用来延续前一个日志块。
日志尾只有一个部份:log_block_trl_no,该值和块头的log_block_hdr_no相等。
上面所说的是一个日志块的内容,在redo log buffer或redo log file on disk中,由很多log block组成。以下图:
1.4 log group和redo log file
log group表示的是redo log group,一个组内由多个大小完全相同的redo log file组成。组内redo log file的数量由变量innodb_log_files_group决定,默许值为2,即两个redo log file。这个组是一个逻辑的概念,并没有真实的文件来表示这是一个组,但是可以通过变量innodb_log_group_home_dir来定义组的目录,redo log file都放在这个目录下,默许是在datadir下。
可以看到在默许的数据目录下,有两个ib_logfile开头的文件,它们就是log group中的redo log file,而且它们的大小完全一致且等于变量innodb_log_file_size定义的值。第一个文件ibdata1是在没有开启innodb_file_per_table时的同享表空间文件,对应于开启innodb_file_per_table时的.ibd文件。
在innodb将log buffer中的redo log block刷到这些log file中时,会以追加写入的方式循环轮训写入。即先在第一个log file(即ib_logfile0)的尾部追加写,直到满了以后向第二个log file(即ib_logfile1)写。当第二个log file满了会清空一部份第一个log file继续写入。
由因而将log buffer中的日志刷到log file,所以在log file中记录日志的方式也是log block的方式。
在每一个组的第一个redo log file中,前2KB记录4个特定的部份,从2KB以后才开始记录log block。除第一个redo log file中会记录,log group中的其他log file不会记录这2KB,但是却会腾出这2KB的空间。以下:
redo log file的大小对innodb的性能影响非常大,设置的太大,恢复的时候就会时间较长,设置的太小,就会致使在写redo log的时候循环切换redo log file。
1.5 redo log的格式
由于innodb存储引擎存储数据的单元是页(和SQL Server中一样),所以redo log也是基于页的格式来记录的。默许情况下,innodb的页大小是16KB(由innodb_page_size变量控制),一个页内可以寄存非常多的log block(每一个512字节),而log block中记录的又是数据页的变化。
其中log block中492字节的部份是log body,该log body的格式分为4部份:
- redo_log_type:占用1个字节,表示redo log的日志类型。
- space:表示表空间的ID,采取紧缩的方式后,占用的空间可能小于4字节。
- page_no:表示页的偏移量,一样是紧缩过的。
- Ÿredo_log_body表示每一个重做日志的数据部份,恢复时会调用相应的函数进行解析。例如insert语句和delete语句写入redo log的内容是不一样的。
以下图,分别是insert和delete大致的记录方式。
1.6 日志刷盘的规则
log buffer中未刷到磁盘的日志称为脏日志(dirty log)。
在上面的说过,默许情况下事务每次提交的时候都会刷事务日志到磁盘中,这是由于变量innodb_flush_log_at_trx_commit的值为1。但是innodb不单单只会在有commit动作后才会刷日志到磁盘,这只是innodb存储引擎刷日志的规则之一。
刷日志到磁盘有以下几种规则:
1.发出commit动作时。已说明过,commit发出后会不会刷日志由变量innodb_flush_log_at_trx_commit控制。
2.每秒刷一次。这个刷日志的频率由变量innodb_flush_log_at_timeout值决定,默许是1秒。要注意,这个刷日志频率和commit动作无关。
3.当log buffer中已使用的内存超过一半时。
4.当有checkpoint时,checkpoint在一定程度上代表了刷到磁盘光阴志所处的LSN位置。
1.7 数据页刷盘的规则及checkpoint
内存中(buffer pool)未刷到磁盘的数据称为脏数据(dirty data)。由于数据和日志都以页的情势存在,所以脏页表示脏数据和脏日志。
上一节介绍了日志是什么时候刷到磁盘的,不单单是日志需要刷盘,脏数据页也一样需要刷盘。
在innodb中,数据刷盘的规则只有一个:checkpoint。但是触发checkpoint的情况却有几种。不管怎样,checkpoint触发后,会将buffer中脏数据页和脏日志页都刷到磁盘。
innodb存储引擎中checkpoint分为两种:
- sharp checkpoint:在重用redo log文件(例如切换日志文件)的时候,将所有已记录到redo log中对应的脏数据刷到磁盘。
- fuzzy checkpoint:一次只刷一小部份的日志到磁盘,而非将所有脏日志刷盘。有以下几种情况会触发该检查点:
- master thread checkpoint:由master线程控制,每秒或每10秒刷入一定比例的脏页到磁盘。
- flush_lru_list checkpoint:从MySQL5.6开始可通过 innodb_page_cleaners 变量指定专门负责脏页刷盘的page cleaner线程的个数,该线程的目的是为了保证lru列表有可用的空闲页。
- async/sync flush checkpoint:同步刷盘或者异步刷盘。例如还有非常多的脏页没刷到磁盘(非常多是多少,有比例控制),这时候候会选择同步刷到磁盘,但这很少出现;如果脏页不是很多,可以选择异步刷到磁盘,如果脏页很少,可以暂时不刷脏页到磁盘
- dirty page too much checkpoint:脏页太多时强迫触发检查点,目的是为了保证缓存有足够的空闲空间。too much的比例由变量 innodb_max_dirty_pages_pct 控制,MySQL 5.6默许的值为75,即当脏页占缓冲池的百分之75后,就强迫刷一部份脏页到磁盘。
由于刷脏页需要一定的时间来完成,所以记录检查点的位置是在每次刷盘结束以后才在redo log中标记的。
MySQL停止时会不会将脏数据和脏日志刷入磁盘,由变量innodb_fast_shutdown={ 0|1|2 }控制,默许值为1,即停止时只做一部份purge,疏忽大多数flush操作(但最少会刷日志),在下次启动的时候再flush剩余的内容,实现fast shutdown。
1.8 LSN超详细分析
LSN称为日志的逻辑序列号(log sequence number),在innodb存储引擎中,lsn占用8个字节。LSN的值会随着日志的写入而逐步增大。
根据LSN,可以获得到几个有用的信息:
1.数据页的版本信息。
2.写入的日志总量,通过LSN开始号码和结束号码可以计算出写入的日志量。
3.可知道检查点的位置。
实际上还可以取得很多隐式的信息。
LSN不但存在于redo log中,还存在于数据页中,在每一个数据页的头部,有一个fil_page_lsn记录了当前页终究的LSN值是多少。通过数据页中的LSN值和redo log中的LSN值比较,如果页中的LSN值小于redo log中LSN值,则表示数据丢失了一部份,这时候候可以通过redo log的记录来恢复到redo log中记录的LSN值时的状态。
redo log的lsn信息可以通过show engine innodb status来查看。MySQL 5.5版本的show结果中只有3条记录,没有pages flushed up to。
—
LOG
—
Log sequence number 2225502463
Log flushed up to 2225502463
Pages flushed up to 2225502463
Last checkpoint at 2225502463
0 pending log writes, 0 pending chkp writes
3201299 log i/o’s done, 0.00 log i/o’s/second
其中:
- Ÿlog sequence number就是当前的redo log(in buffer)中的lsn;
- Ÿlog flushed up to是刷到redo log file on disk中的lsn;
- Ÿpages flushed up to是已刷到磁盘数据页上的LSN;
- last checkpoint at是上一次检查点所在位置的LSN。
innodb从履行修改语句开始:
(1).首先修改内存中的数据页,并在数据页中记录LSN,暂且称之为data_in_buffer_lsn;
(2).并且在修改数据页的同时(几近是同时)向redo log in buffer中写入redo log,并记录下对应的LSN,暂且称之为redo_log_in_buffer_lsn;
(3).写完buffer中的日志后,当触发了日志刷盘的几种规则时,会向redo log file on disk刷入重做日志,并在该文件中记下对应的LSN,暂且称之为redo_log_on_disk_lsn;
(4).数据页不可能永久只停留在内存中,在某些情况下,会触发checkpoint来将内存中的脏页(数据脏页和日志脏页)刷到磁盘,所以会在本次checkpoint脏页刷盘结束时,在redo log中记录checkpoint的LSN位置,暂且称之为checkpoint_lsn。
(5).要记录checkpoint所在位置很快,只需简单的设置一个标志便可,但是刷数据页其实不一定很快,例如这一次checkpoint要刷入的数据页非常多。也就是说要刷入所有的数据页需要一定的时间来完成,中途刷入的每一个数据页都会记下当前页所在的LSN,暂且称之为data_page_on_disk_lsn。
详细说明以下图:
上图中,从上到下的横线分别代表:时间轴、buffer中数据页中记录的LSN(data_in_buffer_lsn)、磁盘中数据页中记录的LSN(data_page_on_disk_lsn)、buffer中重做日志记录的LSN(redo_log_in_buffer_lsn)、磁盘中重做日志文件中记录的LSN(redo_log_on_disk_lsn)和检查点记录的LSN(checkpoint_lsn)。
假定在最初时(12:0:00)所有的日志页和数据页都完成了刷盘,也记录好了检查点的LSN,这时候它们的LSN都是完全一致的。
假定此时开启了一个事务,并立刻履行了一个update操作,履行完成后,buffer中的数据页和redo log都记录好了更新后的LSN值,假定为110。这时候候如果履行show engine innodb status查看各LSN的值,即图中①处的位置状态,结果会是:
以后又履行了一个delete语句,LSN增长到150。等到12:00:01时,触发redo log刷盘的规则(其中有一个规则是innodb_flush_log_at_timeout控制的默许日志刷盘频率为1秒),这时候redo log file on disk中的LSN会更新到和redo log in buffer的LSN一样,所以都等于150,这时候show engine innodb status,即图中②的位置,结果将会是:
再以后,履行了一个update语句,缓存中的LSN将增长到300,即图中③的位置。
假定随后检查点出现,即图中④的位置,正如前面所说,检查点会触发数据页和日志页刷盘,但需要一定的时间来完成,所以在数据页刷盘还未完成时,检查点的LSN或者上一次检查点的LSN,但此时磁盘上数据页和日志页的LSN已增长了,即:
但是log flushed up to和pages flushed up to的大小没法肯定,由于日志刷盘可能快于数据刷盘,也可能等于,还多是慢于。但是checkpoint机制有保护数据刷盘速度是慢于日志刷盘的:当数据刷盘速度超过日志刷盘时,将会暂时停止数据刷盘,等待日志刷盘进度超过数据刷盘。
等到数据页和日志页刷盘终了,即到了位置⑤的时候,所有的LSN都等于300。
随着时间的推移到了12:00:02,即图中位置⑥,又触发了日志刷盘的规则,但此时buffer中的日志LSN和磁盘中的日志LSN是一致的,所以不履行日志刷盘,即此时show engine innodb status时各种lsn都相等。
随后履行了一个insert语句,假定buffer中的LSN增长到了800,即图中位置⑦。此时各种LSN的大小和位置①时一样。
随后履行了提交动作,即位置⑧。默许情况下,提交动作会触发日志刷盘,但不会触发数据刷盘,所以show engine innodb status的结果是:
最后随着时间的推移,检查点再次出现,即图中位置⑨。但是这次检查点不会触发日志刷盘,由于日志的LSN在检查点出现之前已同步了。假定这次数据刷盘速度极快,快到一瞬间内完成而没法捕捉到状态的变化,这时候show engine innodb status的结果将是各种LSN相等。
1.9 innodb的恢复行动
在启动innodb的时候,不管上次是正常关闭或者异常关闭,总是会进行恢复操作。
由于redo log记录的是数据页的物理变化,因此恢复的时候速度比逻辑日志(如二进制日志)要快很多。而且,innodb本身也做了一定程度的优化,让恢复速度变得更快。
重启innodb时,checkpoint表示已完全刷到磁盘上data page上的LSN,因此恢复时仅需要恢复从checkpoint开始的日志部份。例如,当数据库在上一次checkpoint的LSN为10000时宕机,且事务是已提交过的状态。启动数据库时会检查磁盘中数据页的LSN,如果数据页的LSN小于日志中的LSN,则会从检查点开始恢复。
还有一种情况,在宕机前正处于checkpoint的刷盘进程,且数据页的刷盘进度超过了日志页的刷盘进度。这时候候一宕机,数据页中记录的LSN就会大于日志页中的LSN,在重启的恢复进程中会检查到这一情况,这时候超越日志进度的部份将不会重做,由于这本身就表示已做过的事情,无需再重做。
另外,事务日志具有幂等性,所以屡次操作得到同一结果的行动在日志中只记录一次。而二进制日志不具有幂等性,屡次操作会全部记录下来,在恢复的时候会屡次履行二进制日志中的记录,速度就慢很多。例如,某记录中id初始值为2,通过update将值设置为了3,后来又设置成了2,在事务日志中记录的将是无变化的页,根本无需恢复;而二进制会记录下两次update操作,恢复时也将履行这两次update操作,速度比事务日志恢复更慢。
1.10 和redo log有关的几个变量
- innodb_flush_log_at_trx_commit={0|1|2} # 指定什么时候将事务日志刷到磁盘,默许为1。
- 0表示每秒将"log buffer"同步到"os buffer"且从"os buffer"刷到磁盘日志文件中。
- 1表示每事务提交都将"log buffer"同步到"os buffer"且从"os buffer"刷到磁盘日志文件中。
- 2表示每事务提交都将"log buffer"同步到"os buffer"但每秒才从"os buffer"刷到磁盘日志文件中。
- innodb_log_buffer_size:# log buffer的大小,默许8M
- innodb_log_file_size:#事务日志的大小,默许5M
- innodb_log_files_group =2:# 事务日志组中的事务日志文件个数,默许2个
- innodb_log_group_home_dir =./:# 事务日志组路径,当前目录表示数据目录
- innodb_mirrored_log_groups =1:# 指定事务日志组的镜像组个数,但镜像功能好像是强迫关闭的,所以只有一个log group。在MySQL5.7中该变量已移除。
2.undo log
2.1 基本概念
undo log有两个作用:提供回滚和多个行版本控制(MVCC)。
在数据修改的时候,不但记录了redo,还记录了相对应的undo,如果由于某些缘由致使事务失败或回滚了,可以借助该undo进行回滚。
undo log和redo log记录物理日志不一样,它是逻辑日志。可以认为当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录。
当履行rollback时,就能够从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候利用到行版本控制的时候,也是通过undo log来实现的:当读取的某一行被其他事务锁定时,它可以从undo log中分析出该行记录之前的数据是甚么,从而提供该行版本信息,让用户实现非锁定一致性读取。
undo log是采取段(segment)的方式来记录的,每一个undo操作在记录的时候占用一个undo log segment。
另外,undo log也会产生redo log,由于undo log也要实现持久性保护。
2.2 undo log的存储方式
innodb存储引擎对undo的管理采取段的方式。rollback segment称为回滚段,每一个回滚段中有1024个undo log segment。
在之前老版本,只支持1个rollback segment,这样就只能记录1024个undo log segment。后来MySQL5.5可以支持128个rollback segment,即支持128*1024个undo操作,还可以通过变量innodb_undo_logs(5.6版本之前该变量是innodb_rollback_segments)自定义多少个rollback segment,默许值为128。
undo log默许寄存在同享表空间中。
-rw-rw—- 1 mysql mysql 79691776 Mar 31 01:42 /mydata/data/ibdata1
-rw-rw—- 1 mysql mysql 50331648 Mar 31 01:42 /mydata/data/ib_logfile0
-rw-rw—- 1 mysql mysql 50331648 Mar 31 01:42 /mydata/data/ib_logfile1
如果开启了innodb_file_per_table,将放在每一个表的.ibd文件中。
在MySQL5.6中,undo的寄存位置还可以通过变量innodb_undo_directory来自定义寄存目录,默许值为"."表示datadir。
默许rollback segment全部写在一个文件中,但可以通过设置变量innodb_undo_tablespaces平均分配到多少个文件中。该变量默许值为0,即全部写入一个表空间文件。该变量为静态变量,只能在数据库示例停止状态下修改,如写入配置文件或启动时带上对应参数。但是innodb存储引擎在启动进程中提示,不建议修改成非0的值,以下:
2017-03⑶1 13:16:00 7f665bfab720 InnoDB: Expected to open 3 undo tablespaces but was able
2017-03⑶1 13:16:00 7f665bfab720 InnoDB: to find only 0 undo tablespaces.
2017-03⑶1 13:16:00 7f665bfab720 InnoDB: Set the innodb_undo_tablespaces parameter to the
2017-03⑶1 13:16:00 7f665bfab720 InnoDB: correct value and retry. Suggested value is 0
2.3 和undo log相关的变量
undo相关的变量在MySQL5.6中已变得很少。以下:它们的意义在上文中已解释了。
2.4 delete/update操作的内部机制
当事务提交的时候,innodb不会立即删除undo log,由于后续还可能会用到undo log,如隔离级别为repeatable read时,事务读取的都是开启事务时的最新提交行版本,只要该事务不结束,该行版本就不能删除,即undo log不能删除。
但是在事务提交的时候,会将该事务对应的undo log放入到删除列表中,未来通过purge来删除。并且提交事务时,还会判断undo log分配的页会不会可以重用,如果可以重用,则会分配给后面来的事务,避免为每一个独立的事务分配独立的undo log页而浪费存储空间和性能。
通过undo log记录delete和update操作的结果发现:(insert操作无需分析,就是插入行而已)
- delete操作实际上不会直接删除,而是将delete对象打上delete flag,标记为删除,终究的删除操作是purge线程完成的。
- update分为两种情况:update的列会不会是主键列。
- 如果不是主键列,在undo log中直接反向记录是如何update的。即update是直接进行的。
- 如果是主键列,update分两部履行:先删除该行,再插入一行目标行。
3.binlog和事务日志的前后顺序及group commit
提示:建议看看下面的评论。
为了提高性能,通常会将有关联性的多个数据修改操作放在一个事务中,这样可以免对每一个修改操作都履行完全的持久化操作。这类方式,可以看做是人为的组提交(group commit)。
除将多个操作组合在一个事务中,记录binlog的操作也能够按组的思想进行优化:将多个事务触及到的binlog一次性flush,而不是每次flush一个binlog。
事务在提交的时候不但会记录事务日志,还会记录二进制日志,但是它们谁先记录呢?二进制日志是MySQL的上层日志,先于存储引擎的事务日志被写入。
在MySQL5.6之前,当事务提交(即发出commit指令)后,MySQL接收到该信号进入commit prepare阶段;进入prepare阶段后,立即写内存中的二进制日志,写完内存中的二进制日志后就相当于肯定了commit操作;然后开始写内存中的事务日志;最后将二进制日志和事务日志刷盘,它们如何刷盘,分别由变量sync_binlog和innodb_flush_log_at_trx_commit控制。
但由于要保证二进制日志和事务日志的一致性,在提交后的prepare阶段会启用一个prepare_commit_mutex锁来保证它们的顺序性和一致性。但这样会致使开启二进制日志后group commmit失效,特别是在主从复制结构中,几近都会开启二进制日志。
在MySQL5.6中进行了改进。提交事务时,在存储引擎层的上一层结构中会将事务按序放入一个队列,队列中的第一个事务称为leader,其他事务称为follower,leader控制着follower的行动。虽然顺序或者一样先刷二进制,再刷事务日志,但是机制完全改变了:删除原来的prepare_commit_mutex行动,也能保证即便开启了二进制日志,group commit也是有效的。
MySQL5.6中分为3个步骤:flush阶段、sync阶段、commit阶段。
- flush阶段:向内存中写入每一个事务的二进制日志。
- sync阶段:将内存中的二进制日志刷盘。若队列中有多个事务,那末仅一次fsync操作就完成了二进制日志的刷盘操作。这在MySQL5.6中称为BLGC(binary log group commit)。
- commit阶段:leader根据顺序调用存储引擎层事务的提交,由于innodb本就支持group commit,所以解决了由于锁 prepare_commit_mutex 而致使的group commit失效问题。
在flush阶段写入二进制日志到内存中,但是不是是写完就进入sync阶段的,而是要等待一定的时间,多积累几个事务的binlog一起进入sync阶段,等待时间由变量binlog_max_flush_queue_time决定,默许值为0表示不等待直接进入sync,设置该变量为一个大于0的值的好处是group中的事务多了,性能会好一些,但是这样会致使事务的响应时间变慢,所以建议不要修改该变量的值,除非事务量非常多并且不断的在写入和更新。
进入到sync阶段,会将binlog从内存中刷入到磁盘,刷入的数量和单独的二进制日志刷盘一样,由变量sync_binlog控制。
当有一组事务在进行commit阶段时,其他新事务可以进行flush阶段,它们本就不会相互阻塞,所以group commit会不断生效。固然,group commit的性能和队列中的事务数量有关,如果每次队列中只有1个事务,那末group commit和单独的commit没甚么区分,当队列中事务愈来愈多时,即提交事务越多越快时,group commit的效果越明显。
总结
到此这篇关于MySQL事务日志(redo log和undo log)的文章就介绍到这了,更多相关MySQL事务日志redo log和undo log内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持!
文章来源:丸子建站
文章标题:再次详解MySQL事务日志(redo log和undo log)的详细分析
https://www.wanzijz.com/view/88327.html
相关文章
Related articles
- 1 ORACLE开发知识:通过 plsql 连接远程 Oracle数据库的多种方法 2023-09-22 08:23:11
- 2 python 浏览器点击 2023-09-22 08:23:10
- 3 oracle Dbeaver存储进程语法详解 2023-09-22 08:23:10
- 4 MySQL 原理:InnoDB文件的存储结构格式解析 2023-09-22 08:23:08
- 5 SQL开发知识:group by 按某一时间段分组统计并查询 2023-09-22 08:23:08
- 6 SQL基础:通过T-SQL语句创建游标与实现数据库加解密功能 2023-09-22 08:23:07
- 7 python 浮点转定点 2023-09-22 08:23:05
- 8 数据库安装:Windows10安装Oracle19c数据库图文详细教程 2023-09-22 08:23:04
- 9 SQL开发知识:Sql Server 视图数据的增删改查教程 2023-09-22 08:23:03
- 10 MySQL数据库开发:数据库操作DQL正则表达式 2023-09-22 08:23:02
随机看看
NEW ARTICLE
- 1 香港云主机租用如何选择 04-28
- 2 日本海外vps服务器租用如何选择公司 06-09
- 3 css为啥会加载失败 03-24
- 4 web服务器搭建网站的有哪些方法 06-25
- 5 服务器空间租用的收费标准是什么 06-13
- 6 韩顺平绝活Redis视频全集,学习不再难! 04-21
热门文章
HOT ARTICLE
- 1 显卡:centos查看显卡信息的方法 04-07
- 2 黑客利用SQLServer数据库成功实行盲注入攻击 05-11
- 3 android开发工具有哪些?又该如何进行选择? 02-13
- 4 公众号和订阅号有什么区别?公众号和订阅号有什么优势? 01-30
- 5 python怎么获取列表元素的下标 03-23
- 6 navicat:navicat怎样连接mongodb 04-04
- 7 速率:centos7怎么查看网卡速率 04-07
- 8 字体:小程序字体加粗怎么实现 04-09
- 9 公众号登录的方法是什么?公众号登录失败的原因是什么? 01-30
- 10 【mssql中实现多个like查询的方式】 04-21