文章目录
- 事务日志-Redo Log
- 2.1 Redo Log
- 2.1.1 Redo Log与持久性
- 2.1.2 Redo Log的工作原理
- 2.1.3 Redo Log的落盘策略
- 2.1.4 Redo Log的系统参数
事务日志-Redo Log
事务的隔离性是通过锁实现,而事务的原子性、和持久性则是通过事务日志实现。在MySQL中,事务日志分为两类,一个是Redo Log
,也叫重做日志,另一个是Undo Log
,也叫回滚日志;其中Redo Log保证事务的持久性,Undo Log保证的是事务的原子性;
2.1 Redo Log
2.1.1 Redo Log与持久性
事务开启后,执行的所有的操作都是记录在事务日志中,这部分数据并没有写入磁盘表,需要把当前事务提交,才会将事务日志记录的数据写入到磁盘表中。Redo Log是用于保证事务的ACID中的持久性的,关于什么是持久性我们必须弄清楚这一点。
- 事务的持久性:事务提交成功后,数据被保存到磁盘表中,即使发生系统崩溃、断电或其他故障,只要表、磁盘等软硬件设备不被损坏,那么数据将永久保持在磁盘中。
这里存在一个疑问,事务都提交成功了,系统发生崩溃、断电或其他故障不是本就不会影响到磁盘表中的数据吗?当然前提是磁盘表中的数据没有损坏,那这个持久性到底保障的是什么呢?
需要注意:事务的持久性指的是事务一旦提交成功,才能保障后续的流程(崩溃、宕机等问题的处理)。**可不是保证事务一定能提交成功。**如果事务在提交过程中出现问题,这个问题包括事务运行过程中的问题(一般是客户端的代码问题),也包括MySQL服务器自身的问题(一般是执行commit命令时宕机、系统奔溃等)。但不管是客户端或者是MySQL服务器本身的问题导致的提交失败,MySQL都会将其标记为提交失败,客户端接收到MySQL响应的提交失败请求后可以做其他的补偿处理。
如果一个事务被标记为提交成功,那么数据能够正常写入磁盘表,并且不怕MySQL宕机、服务器崩溃等,如果一个事务被标记为失败,那么该出现的问题还是会出现的。那么也可以这么理解:如何让事务能够快速被标记为成功,或许才是是事务日志真正所要考虑的问题,毕竟能够快速标记为成功,那就少一份执行commit时MySQL宕机、服务器崩溃的风险。
2.1.2 Redo Log的工作原理
Redo日志也叫重做日志,在InnoDB存储引擎中使用。它记录了数据在内存中更改之后但还未持久化到磁盘表之前的信息。它的主要作用是在系统崩溃后能够重新执行(redo)那些已经提交但尚未写入磁盘的数据更改。如果在事务提交时,此时数据库崩溃或者宕机,那么当系统重启进行恢复时,就可以根据Redo Log中记录的日志,把数据库恢复到崩溃前的一个状态。因此Redo Log 是InnoDB实现事务持久性的强力保证。
Tips:Redo Log主要保障的是事务的持久性,即只要事务提交成功,那么数据就能够永久保存到数据库中,否则就属于提交失败,就应该进行事务回滚(根据Undo 日志回滚),客户端也可以做一些事务提交失败的代码流程。
- Redo的运行流程:
首先在操作表时,会将表数据从磁盘(.idb)加载到内存缓冲池中(Buffer Pool),对表所有的操作都会记录一份到Redo Buffer日志(内存中的Redo日志)中,其根据一定的策略将数据刷新到Redo Log中(磁盘中的Redo日志)。在事务最终要提交时(执行了commit),如果数据库或系统突然宕机,那么当数据库或系统重启时,就可以根据Redo Log日志中的记录进行数据的恢复。
Redo Log的工作原理如图所示:
在提交事务时,为什么不直接将数据写入数据库表呢?而是要先写入Redo Log中呢?看似好像“多此一举”?其实不然。写入Redo Log的好处如下:
- 原因一:Redo Log的结构简单。
Redo Log 记录的是物理层面上的数据修改,因此Redo也叫物理日志。这些修改记录包含了数据页的物理地址(Page Number)和修改的具体内容(如页内数据的前后变化)。在系统重启时,InnoDB 会读取 Redo Log 文件,并根据其中的记录重做对数据页的修改。
Redo Log的日志格式:
正因为Redo Log中记录的数据结构简单,只记录一些物理地址以及一些变更状态等信息。因此数据先写入Redo Log要比直接写入到表快多了。其次,Redo Log作为“临时存储的数据区域”,当Redo Buffer中的数据已经到达一定大小后,Redo Buffer也会将这部分数据写入到Redo Log中,此时数据还未提交,但是已经写入到磁盘中了。
Tips:上面流程中这种先写日志,再写磁盘,只有日志写入成功,才算事务提交成功的技术思想在MySQL也叫做
WAL
技术 (Write-Ahead Logging
日志先行)。
- 原因二:顺序IO性能远高于随机IO。
数据在MySQL中存储是以页为单位,事务中操作的数据可能遍布在不同的页中,如果直接写入到磁盘中对应的页中,是随机IO写入,效率低。
而Redo Log是通过往Redo Log日志中追加数据的方式,属于顺序IO,效率高。这样可能会影响Redo Log恢复数据时的性能,但可以保证在提交时期能够快速写入Redo Log日志记录本次事务的更改。
2.1.3 Redo Log的落盘策略
事务的日志是先写入到redo log buffer
中的,并且这个过程是非常快的,那redo log buffer在什么时候会写入磁盘呢?
redo log buffer
不是直接将日志内容刷盘到redo log file
中,而是先刷入到操作系统的文件系统缓存 (page cache
)中去。最后,日志内容会从操作系统的文件系统缓存中刷到磁盘的日志文件中,至于什么时候触发这个动作,MySQL的innoDB引擎提供了3种策略可选。
Tips:Redo Log Buffer 刷新到 page cache 后,如果是MySQL宕机则问题不大,但是如果整个系统宕机数据将会丢失,因为数据都保存在操作系统的
page cache
中。不过这个过程很快,而且整个系统宕机概率相对MySQL会小很多。
InnoDB
引擎提供了 innodb_flush_log_at_trx_commit
参数,该参数控制 commit
提交事务时,如何将 redo log buffer
中的日志刷新到 redo log file
的3种策略,取值有0、1、2;默认为1。
mysql> select @@innodb_flush_log_at_trx_commit;
+----------------------------------+
| @@innodb_flush_log_at_trx_commit |
+----------------------------------+
| 1 |
+----------------------------------+
1 row in set (0.00 sec)
- 0:代表每秒将
Redo Buffer
中的数据刷到OS buffer
然后立即从OS buffer
刷到Redo Log磁盘文件中。
为0时,后台线程每隔1秒进行一次重做日志的刷盘操作。在这种情况下,MySQL宕机最多丢失1s内的事务数据,这种方式效率最高,但是安全性最低。
- 1:代表每次提交事务都将
Redo Buffer
同步到OS Buffer
然后立即从OS Buffer
刷到Redo Log磁盘文件中**(默认值)**。
为1时,每次事务提交时都将进行同步, 执行主动刷盘操作。在这种情况下,MySQL宕机最多丢失1次事务的数据,安全性最高,效率偏低。
- 2:代表每次提交都将
Redo Buffer
中的数据刷到OS Buffer
,然后再隔一秒从OS Buffer
刷到Redo Log磁盘文件中。
为2时,只要事务提交成功,redo log buffer
中的内容只写入文件系统缓存(pagecache
)。在这种情况下,如果是MySQL宕机,最多丢失1次事务的数据,但是如果是操作系统宕机,则可能会丢失1s内的数据。安全性和效率折中。
- 测试不同的redo刷盘策略对性能的影响:
mysql> truncate userinfo;
Query OK, 0 rows affected (0.01 sec)
mysql> set global innodb_flush_log_at_trx_commit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> call test_insert(10000);
Query OK, 1 row affected (0.42 sec)
mysql> truncate userinfo;
Query OK, 0 rows affected (0.01 sec)
mysql> set global innodb_flush_log_at_trx_commit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> call test_insert(10000);
Query OK, 1 row affected (17.36 sec)
mysql> truncate userinfo;
Query OK, 0 rows affected (0.01 sec)
mysql> set global innodb_flush_log_at_trx_commit=2;
Query OK, 0 rows affected (0.00 sec)
mysql> call test_insert(10000);
Query OK, 1 row affected (0.46 sec)
mysql>
Redo Buffer 除了上面3种策略进行刷盘以外,还有另外一种特殊的场景:当redo log buffer
占用的空间即将达到 innodb_log_buffer_size
一半的时候,后台线程会主动写盘。需要注意,由于这个事务并没有提交,所以这个写盘动作只是 write
,而没有调用 fsync
,也就是只留在了文件系统的 page cache
。
2.1.4 Redo Log的系统参数
innodb_log_buffer_size
:Redo Buffer
的大小,默认16Minnodb_log_file_size
:单个Redo Log
事务日志文件的最大大小,默认48Minnodb_log_files_group
:Redo Log
日志文件的个数,默认2个innodb_log_group_home_dir
:Redo Log
的存放路径;默认值为./
代表当前MySQL的数据目录(Linux默认是/var/lib/mysql
)innodb_log_checksums
:启用或禁用Relo log
数据页的校验,默认开启。innodb_log_compressed_pages
:指定是否将重新压缩的页写入Redo Log
,默认是开启状态
show variables like '%innodb_log%';