undo日志分析

undolog 结构undolog是一个基于log-structured存储的分布式事务日志引擎，它的目标是在保证高吞吐和低延迟的同时，提供强一致性和高可靠性。

本文将详细介绍undolog的结构。

1. 概述undolog将所有的操作都视为事务，并以事务为单位进行管理和存储。

每个事务包括一个或多个操作（例如读取、写入、修改等），并由一个全局唯一的事务ID来标识。

undolog将所有的事务日志划分为几个日志分区（Log Partition），每个分区包含若干日志段（Log Segment）。

2. 日志分区日志分区是undolog的基本单位，它可以是一个物理分区或者是一个逻辑分区。

undolog将一个物理分区划分为若干个逻辑分区，并将每个逻辑分区映射到一个或多个物理分区上。

这样，当一个逻辑分区达到其容量限制时，undolog可以自动将其数据迁移到其他物理分区上，从而实现动态扩容和平衡负载。

日志段是一个固定大小的文件，用于存储一组事务的日志。

undolog将所有的日志段组织成一个环形链表，形成一个不断增长的日志序列。

每个日志段包括一个头部（Header）和若干条日志记录（Log Record）。

3.1 头部每个日志段的头部包括如下信息：- 日志段ID：用于标识该日志段的全局唯一ID；- 下一个日志段ID：用于指向链表中下一个日志段的ID；- 上一个日志段ID：用于指向链表中上一个日志段的ID；- 日志条目数：该日志段中存储的日志记录数；- 日志总大小：该日志段中存储的所有日志记录（包括头部）的总大小。

- 事务ID：该日志记录所属的事务ID；- 日志类型：该日志记录的类型，包括：开始（start）、提交（commit）、中止（abort）、写入（write）和读取（read）；- 数据：该日志记录所涉及的数据，包括：键（key）和值（value）。

4. 索引为了快速定位每个事务的日志记录，undolog维护了一个基于B+树的索引结构。

Oracleredo与undoUndo and redoOracle最重要的两部分数据，undo 与redo，redo（重做信息）是oracle在线（或归档）重做⽇志⽂件中记录的信息，可以利⽤redo重放事务信息，undo（撤销信息）是oracle在undo段中记录的信息，⽤于撤销或回滚事务。

1 redo重做⽇志⽂件redo log，是数据库的事务⽇志，oracle维护着2类重做⽇志，在线重做⽇志⽂件和归档重做⽇志⽂件，归档⽇志⽂件就是重做⽇志的副本，系统将⽇志⽂件填满时arch进程会在另⼀个位置建⽴⼀个在线重做⽇志的副本每个oracle数据库⾄少有2个重做⽇志组，以便切换⽇志，每个⽇志组⾄少有1个⽇志组成员，这些在线重做⽇志⽂件是以循环写的⽅式使⽤，2 undo你对数据库执⾏修改时，数据库会⽣成undo信息，以便回滚到更改前的状态，undo⽤于取消⼀条语句或⼀组语句的作⽤，undo在数据库内部存放在⼀组特殊的段中，为undo段（回滚段 rollback segment），利⽤undo，数据库只是逻辑的恢复到原来的样⼦，所有修改都逻辑的取消，但是数据结构以及数据块本⾝在回滚后可能不⼤相同，对于undo⽣成对于直接路径操作不适⽤，直接路径操作能够绕过表上的undo⽣成。

SQL>set autotrace traceonly statisticsSQL>select*from t;--not first executeno rows selectedStatistics----------------------------------------------------------0 recursive calls0 db block gets3 consistent gets0 physical reads0 redo size995 bytes sent via SQL*Net to client374 bytes received via SQL*Net from client1 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)0 rows processedSQL>insert into t select*from all_objects;49789 rows created.SQL>rollback;Rollback complete.SQL>select*from t;no rows selectedStatistics----------------------------------------------------------0 recursive calls0 db block gets689 consistent gets -----I/O0 physical reads0 redo size995 bytes sent via SQL*Net to client374 bytes received via SQL*Net from client1 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)0 rows processedInsert导致⼀些块增加到表的⾼⽔位线(HWM),这些块没有因为回滚⽽消失，select extent_id, bytes, blocks from user_extentswhere segment_name = 'X' order by extent_id; 分配给表的存储空间—这个表没有使⽤任何区段3 undo 跟redo如何协作尽管undo信息存储在undo表空间或undo段中，但也会受到redo保护，会把undo信息当成表数据或索引数据⼀样，对undo的修改会⽣成⼀些redo，将记⼊重做⽇志，将undo数据增加到undo段中，并像其他部分的数据⼀样，在缓冲区缓存中得到缓存Insert-update-delete场景3.1 insertInsert语句，都会⽣成redo跟undo信息，插⼊发⽣后，如下图缓存了⼀下已修改的undo块，索引块和表数据块，这些块得到重做⽇志缓冲区相应条⽬的保护1假象现在系统崩溃，sga全部被清空，但是我们不需要sga的中的任何内容，重启动时就好像这个事务就没发⽣过，没有将任何修改的块刷新输出到磁盘，也没有任何redo信息刷新输出到磁盘，我们不需要这些undo或redo信息来实现实例失败恢复2假象：缓冲区缓存已满Dbwr进程要把已修改的块从缓存输出到磁盘，⾸先要求lgwr进程将保护这些数据库的redo条⽬输出到磁盘，dbwr在将任何修改的块输出到磁盘之前，都必须要求lgwr进程先刷新输出到redo⽇志，3.2 updateUpdate所带来的⼯作与insert⼤体⼀样，不过undo信息量更⼤，update，要保存系统的前映像，缓冲区中会有更多的undo块，为了撤销update，如果必要，已修改的数据库表和索引都会存在缓存中，其中重做⽇志有的已经输出到磁盘，有的还在redo buffer 中1 系统崩溃：启动时，oracle会读取重做⽇志，给定系统的当前状态，利⽤重做⽇志⽂件中对应的插⼊的redo条⽬，并利⽤仍在缓冲区中对应的redo条⽬，oracle会前滚插⼊，连接断开，oracle发现事务从未提交，因此将其回滚，利⽤undo，2 应⽤回滚事务Oracle发现这个事务的undo信息可能缓存在undo段中，也肯能已经刷新输出到磁盘，会把und信息应⽤到缓存中的数据和索引上，不在缓存中，则先要读⼊到缓存，恢复其原来的⾏，并刷新输出数据⽂件，回滚过程不涉及重组⽇志，只有恢复和归档才会读取重做⽇志，重做⽇志是⽤来写的，不⽤于读，3 deleteDelete 会⽣成undo⽇志，块将被修改，并把redo⽇志发送到重做⽇志缓冲区，与update类似4 commit已经修改的块放在缓冲区缓存中，可能已经输出到磁盘，重做这个事务所需的全部redo都安全的存放在磁盘上，undo信息会⼀直存在，除⾮undo段回绕并重⽤了这些undo块，4 提交和回滚处理Commit：commit并没有做太多的⼯作，Commit开销，频繁提交，会增加与数据库的往返同学，如果每个记录都提交，⽣成的往返通信量会⼤得多，每次提交时，必须等待redo写到磁盘，这会导致等待在commit之前可能：已经在sga中⽣成了undo 块，已经在sga中⽣成了已修改的数据块，已经在sga中⽣成了对应的2想的redo信息，取决于前3项的⼤⼩，已经这些花费的时间，前⾯的数据可能已经输出到磁盘，已经得到全部锁需要的锁在实际commit时， 1为事务⽣成⼀个scn（系统改变号），scn⽤于保证事务的顺序，并⽀持失败恢复，scn还⽤于保证数据库中的读⼀致性和检查点，每次有⼈commit，scn都会增加1。

mysql⽇志：redolog、binlog、undolog区别与作⽤⼀、redo log 重做⽇志 作⽤：确保事务的持久性。

防⽌在发⽣故障的时间点，尚有脏页未写⼊磁盘，在重启mysql服务的时候，根据redo log进⾏重做，从⽽达到事务的持久性这⼀特性。

内容：物理格式的⽇志，记录的是物理数据页⾯的修改的信息，其redo log是顺序写⼊redo log file的物理⽂件中去的。

⼆、bin log 归档⽇志（⼆进制⽇志） 作⽤：⽤于复制，在主从复制中，从库利⽤主库上的binlog进⾏重播，实现主从同步。

⽤于数据库的基于时间点的还原。

内容：逻辑格式的⽇志，可以简单认为就是执⾏过的事务中的sql语句。

但⼜不完全是sql语句这么简单，⽽是包括了执⾏的sql语句（增删改）反向的信息，也就意味着delete对应着delete本⾝和其反向的insert；update对应着update执⾏前后的版本的信息；insert对应着delete和insert本⾝的信息。

binlog 有三种模式：Statement（基于 SQL 语句的复制）、Row（基于⾏的复制）以及 Mixed（混合模式）三、undo log 回滚⽇志 作⽤：保存了事务发⽣之前的数据的⼀个版本，可以⽤于回滚，同时可以提供多版本并发控制下的读（MVCC），也即⾮锁定读 内容：逻辑格式的⽇志，在执⾏undo的时候，仅仅是将数据从逻辑上恢复⾄事务之前的状态，⽽不是从物理页⾯上操作实现的，这⼀点是不同于redo log的。

redo log mysql，如果每次更新操作都要写进磁盘，然后磁盘要找到对应记录，然后再更细，整个过程io成本、查找成本都很⾼。

解决⽅案：WAL技术（Write-Ahead Logging）。

先写⽇志，再写磁盘。

具体来说，当有⼀条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log⾥⾯，并更新内存，这个时候更新就算完成了。

该问题目前的分析：1、9312-A主板(1/13)忽然出现硬件故障，导致该单板不停复位。

Jan 19 2012 14:29:07 Quidway %%01CSSM/4/STACKBACKUP(l)[33]:This cluster CSS compete result is backup.Jan 19 2012 14:29:15 Quidway %%01ALML/4/CLOCKFAULT(l)[50]:The"CLK_33M_CHK" sensor15 of MPU board[1/13] detect clock signal faultJan 19 2012 14:29:15 Quidway %%01ALML/4/CLOCKFAULT(l)[51]:The"CLK_125M_CHK" sensor16 of MPU board[1/13] detect clock signal faultJan 19 2012 14:29:15 Quidway %%01ALML/4/CLOCKFAULT_RESUME(l)[55]:The "CLK_125M_CHK" sensor16 of MPU board[1/13] detect clock signal fault resume Jan 19 2012 14:29:15 Quidway %%01ALML/4/CLOCKFAULT(l)[56]:The"CLK_125M_CHK" sensor16 of MPU board[1/13] detect clock signal faultJan 19 2012 14:29:15 Quidway %%01ALML/3/CPU_RESET(l)[57]:The canbus node of MPU board[1/13] detects that CPU was reset.2、由于该单板的复位导致9312-A备板(1/14)也出现异常复位，应该是由于1/13单板复位导致，怀疑是1/13板一直复位，自动回退到了老的版本，此时出现主备板版本不一致引发。

InnoDB事务⽇志（redolog和undolog）详解数据库通常借助⽇志来实现事务，常见的有undo log、redo log，undo/redo log都能保证事务特性，undolog实现事务原⼦性，redolog实现事务的持久性。

为了最⼤程度避免数据写⼊时io瓶颈带来的性能问题，MySQL采⽤了这样⼀种缓存机制：当query修改数据库内数据时，InnoDB先将该数据从磁盘读取到内存中，修改内存中的数据拷贝，并将该修改⾏为持久化到磁盘上的事务⽇志（先写redo log buffer，再定期批量写⼊），⽽不是每次都直接将修改过的数据记录到硬盘内，等事务⽇志持久化完成之后，内存中的脏数据可以慢慢刷回磁盘，称之为Write-Ahead Logging。

事务⽇志采⽤的是追加写⼊，顺序io会带来更好的性能优势。

为了避免脏数据刷回磁盘过程中，掉电或系统故障带来的数据丢失问题，InnoDB采⽤事务⽇志（redo log）来解决该问题。

⼀、先简单了解⼏个概念数据库数据存放的⽂件称为data file；⽇志⽂件称为log file；数据库数据是有缓存的，如果没有缓存，每次都写或者读物理disk，那性能就太低下了。

数据库数据的缓存称为data buffer，⽇志（redo）缓存称为log buffer。

内存缓冲池buffer pool如果mysql不⽤内存缓冲池，每次读写数据时，都需要访问磁盘，必定会⼤⼤增加I/O请求，导致效率低下。

所以Innodb引擎在读写数据时，把相应的数据和索引载⼊到内存中的缓冲池(buffer pool)中，⼀定程度的提⾼了数据读写的速度。

buffer pool：占最⼤块内存，⽤来存放各种数据的缓存包括有索引页、数据页、undo页、插⼊缓冲、⾃适应哈希索引、innodb存储的锁信息、数据字典信息等。

⼯作⽅式总是将数据库⽂件按页(每页16k)读取到缓冲池，然后按最近最少使⽤(lru)的算法来保留在缓冲池中的缓存数据。

undo⽇志undo⽇志作⽤因⼀些原因（机器宕机/操作系统错误/⽤户主动rollback等)导致事务执⾏到⼀半，但这时事务的执⾏已经让很多信息修改了（提交前就会边执⾏边修改记录），但还有部分未执⾏，为了保证事务的⼀致性与原⼦性，要么全都执⾏成功，要么全都失败，所以就需要回滚，⽽rollback需要旧值依据，⽽这些旧值记录就存储在undo⽇志中。

redo⽇志记录记录时机InnoDB存储引擎在实际的进⾏增删改操作时，每操作⼀条记录都会先把对应的undo⽇志记录下来。

undo⽇志通⽤结构undo⽇志存储在类型为FIL_PAGE_UNDO_LOGO的页⾯中，⽽每条记录添加到数据页中时，都会隐式的⽣成两个列trix_id和roll_pointer，trix_id就是事务id，roll_pointer是指向记录对应的undo⽇志的⼀个指针end of record：本条undo⽇志在页中结束地址undo type：undo⽇志类型undo no：undo⽇志编号，事务没提交时，每⽣成⼀条undo⽇志就递增1table id：本条undo ⽇志对应记录所在table id（information_schema库中表innodb_sys_tables查看）主键各列信息列表：<len, value>关键列占⽤空间和真实值信息列表start of record：本条undo ⽇志在页中开始的地址各操作所对应的undo⽇志结构不同1. INSERT：回滚时，就是删除掉新增的这条记录。

暂时只考虑聚簇索引插⼊情况，因为⼆级索引也包含主键，所以删除时也会根据主键信息把⼆级索引中的内容也删除名称内容undo type TRX_UNDO_INSERT_REC2. DELETE：记录被删除时，该记录头部信息的delete_mask会置为1，且会根据头部信息中的next_record属性组成⼀个垃圾链表，⽽这个链表中各记录占⽤的空间可以被重⽤，数据页PAGE HEADER中有个PAGE_FREE属性记录了这个链表的头节点。

mysql⽇志redolog、undolog、binlog以及作⽤什么是事务⽇志？事务要保证ACID的完整性必须依靠事务⽇志做跟踪，每⼀个操作在真正写⼊数据数据库之前，先写⼊到⽇志⽂件中如要删除⼀⾏数据会先在⽇志⽂件中将此⾏标记为删除，但是数据库中的数据⽂件并没有发⽣变化。

只有在(包含多个sql语句)整个事务提交后，再把整个事务中的sql语句批量同步到磁盘上的数据库⽂件。

在事务引擎上的每⼀次写操作都需要执⾏两遍如下过程：1. 先写⼊⽇志⽂件中写⼊⽇志⽂件中的仅仅是操作过程,⽽不是操作数据本⾝,所以速度⽐写数据库⽂件速度要快很多。

2. 然后再写⼊数据库⽂件中写⼊数据库⽂件的操作是重做事务⽇志中已提交的事务操作的记录。

⽇志组⼀般不⽌设置⼀个⽇志⽂件，⼀个⽂件写满之后使⽤另外⼀个⽇志⽂件提⾼服务器效率。

⽇志⽂件的⽇志同步到磁盘后空间会⾃动释放，单个⽇志⽂件不宜设置过⼤，如果⽇志⽂件过⼤mysql进程在把⽇志同步到数据⽂件的时候可能会崩溃。

事务⽇志⽤途事务⽇志可以帮助提⾼事务的效率，使⽤事务⽇志，存储引擎在修改表的数据的时候只需要修改其内存拷贝，再把该⾏为记录到持久在磁盘的事务⽇志中，⽽不⽤每次都将修改的数据本⾝持久到磁盘。

事务⽇志采⽤的是追加⽅式，因此写⽇志的操作是磁盘上⼀⼩块区域的顺序IO，⽽不像随机IO需要磁盘在多个地⽅移动。

所以采⽤事务⽇志的⽅式相对来说要快的多，事务⽇志持久后，内存中的修改在后台慢慢的刷回磁盘。

期间如果系统发⽣崩溃，存储引擎在重启的时候依靠事务⽇志⾃动恢复这部分被修改数据。

redo log在innoDB的存储引擎中，事务⽇志通过重做(redo)⽇志和innoDB存储引擎的⽇志缓冲(InnoDB Log Buffer)实现。

事务开启时，事务中的操作，都会先写⼊存储引擎的⽇志缓冲中，在事务提交之前，这些缓冲的⽇志都需要提前刷新到磁盘上持久化，这就是DBA们⼝中常说的“⽇志先⾏”(Write-Ahead Logging)。

redo和undo⽇志在数据库系统中，既有存放数据的⽂件，也有存放⽇志的⽂件。

⽇志在内存中也是有缓存Log buffer，也有磁盘⽂件log file，本⽂主要描述存放⽇志的⽂件。

MySQL中的⽇志⽂件，有这么两类常常讨论到：undo⽇志与redo⽇志。

1 undo1.1 undo是啥undo⽇志⽤于存放数据修改被修改前的值，假设修改 tba 表中 id=2的⾏数据，把Name=’B’ 修改为Name = ‘B2’ ，那么undo⽇志就会⽤来存放Name=’B’的记录，如果这个修改出现异常，可以使⽤undo⽇志来实现回滚操作，保证事务的⼀致性。

对数据的变更操作，主要来⾃ INSERT UPDATE DELETE，⽽UNDO LOG中分为两种类型，⼀种是 INSERT_UNDO（INSERT操作），记录插⼊的唯⼀键值；⼀种是 UPDATE_UNDO（包含UPDATE及DELETE操作），记录修改的唯⼀键值以及old column记录。

Id Name1A2B3C4D1.2 undo参数MySQL跟undo有关的参数设置有这些：1 mysql> show global variables like '%undo%';2 +--------------------------+------------+3 | Variable_name | Value |4 +--------------------------+------------+5| innodb_max_undo_log_size |1073741824 |6| innodb_undo_directory | ./ |7| innodb_undo_log_truncate |OFF |8| innodb_undo_logs |128 |9| innodb_undo_tablespaces |3 |10 +--------------------------+------------+1112 mysql> show global variables like '%truncate%';13 +--------------------------------------+-------+14 | Variable_name | Value |15 +--------------------------------------+-------+16| innodb_purge_rseg_truncate_frequency |128 |17| innodb_undo_log_truncate |OFF |18 +--------------------------------------+-------+innodb_max_undo_log_size控制最⼤undo tablespace⽂件的⼤⼩，当启动了innodb_undo_log_truncate 时，undo tablespace 超过innodb_max_undo_log_size 阀值时才会去尝试truncate。

MySQL之binlog、redolog和undolog简介⽇志是MySQL数据库的重要组成部分，记录着数据库运⾏期间各种状态信息。

MySQL中⽇志类型有很多种，但对于开发来说，最常见和最重要的就是binlog、redolog和undolog。

本篇⽂章主要对这三种⽇志类型做⼀个简要的介绍。

前置知识逻辑⽇志：可以简单得理解为sql语句；物理⽇志：MySQL中数据都是保存在数据页中的，物理⽇志记录的是数据页上的变更；binlogbinlog是MySQL Server层记录的⽇志，也就是说，不管MySQL使⽤的什么存储引擎，都会有bin log产⽣。

binlog是MySQL中最重要的⽇志，它记录了所有的DDL和DML（除了查询语句）语句，即所有修改数据的操作，以⼆进制的形式存储在磁盘中，binlog是⼀种逻辑⽇志。

binlog 作⽤主从复制：在Mater端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从⽽达到主从数据⼀致；数据恢复：基于时间点，可以通过mysqlbinlog⼯具来恢复数据；binlog 主从复制原理MySQL主从同步主要依靠binlog来实现。

这⾥简单介绍⼀下基本原理。

主节点 binlog dump 线程当从节点连接主节点时，主节点会创建⼀个log dump 线程，⽤于发送binlog的内容。

在读取binlog中的操作时，此线程会对主节点上的binlog加锁，当读取完成，甚⾄在发动给从节点之前，锁会被释放；从节点I/O线程当从节点上执⾏start slave命令之后，从节点会创建⼀个I/O线程⽤来连接主节点，请求主库中更新的binlog。

I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relaylog中；从节点SQL线程SQL线程负责读取relaylog中的内容，解析成具体的操作并执⾏，最终保证主从数据的⼀致性；binlog的内容上⾯说了，binlog是⼀种逻辑⽇志，可以简单得理解为sql语句，但是实际上还包含着执⾏的sql语句的反向逻辑。

binlog，redo log，undo log区别什么是binlogbinlog日志用于记录所有更新且提交了数据或者已经潜在更新提交了数据（例如，没有匹配任何行的一个DELETE）的所有语句。

语句以“事件”的形式保存，它描述数据更改。

binlog作用1.恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。

2.在主复制服务器上记录所有将发送给从服务器的语句。

binlog 主要参数log_bin设置此参数表示启用binlog功能，并指定路径名称innodb_flush_log_at_trx_commit = N：N=0 –每隔一秒，把事务日志缓存区的数据写到日志文件中，以及把日志文件的数据刷新到磁盘上；N=1 –每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上；N=2 –每事务提交的时候，把事务日志数据从缓存区写到日志文件中；每隔一秒，刷新一次日志文件，但不一定刷新到磁盘上，而是取决于操作系统的调度；sync_binlog = N：N>0 —每向二进制日志文件写入N条SQL或N个事务后，则把二进制日志文件的数据刷新到磁盘上；N=0 —不主动刷新二进制日志文件的数据到磁盘上，而是由操作系统决定；推荐配置组合：N=1,1 —适合数据安全性要求非常高，而且磁盘IO写能力足够支持业务，比如充值消费系统；N=1,0 —适合数据安全性要求高，磁盘IO写能力支持业务不富余，允许备库落后或无复制；N=2,0或2,m(0<m<100) —适合数据安全性有要求，允许丢失一点事务日志，复制架构的延迟也能接受；N=0,0 —磁盘IO写能力有限，无复制或允许复制延迟稍微长点能接受，例如：日志性登记业务；Undo LogUndo Log是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用UndoLog来实现多版本并发控制(简称：MVCC)。

数据库的⽇志数据库都具有事务⽇志，⽤于记录所有事务以及每个事务对数据库所做的修改。

事务⽇志是数据库的重要组件，如果系统出现故障，则可能需要使⽤事务⽇志将数据库恢复到⼀致状态。

删除或移动事务⽇志以前，必须完全了解此操作带来的后果。

事务⽇志⽀持以下操作：恢复个别的事务。

在 SQL Server 启动时恢复所有未完成的事务。

将还原的数据库、⽂件、⽂件组或页前滚⾄故障点。

⽀持事务复制⽀持备份服务器解决⽅案。

那时有两个痛点：1，某个⽤户电脑忽然断电，数据写⼊不完整，导致⼤家都不能⽤了；2、多个⽤户对同⼀条记录进⾏写操作，或读与写不致，或ID增量重号。

现在的数据库系统（Oracel、DB2、MS sql、Mysql等）都⽀持多⽤户，所有的数据库系统（包括Exchange），都是把数据先写到⽇志中，等某个时机（⽐如：确认commit）后再写到数据库记录中，⽇志是数据库最重要的数据之⼀，理解⽇志是相当重要的。

为什么要⽤⽇志呢？就是要解决Foxfro多⽤户的痛点⼀啊。

⽇志⼀般分成Undo与Redo：Undo⼀般⽤于事务的取消与回滚，记录的是数据被修改前的值，Redo⼀般⽤于恢复已确认但未写⼊数据库的数据，记录的是数据修改后的值，例如：数据库忽然断电重启，数据库启动时⼀般要做⼀致性检查，会把已写到Redo的数据但未写⼊数据库的数据重做⼀遍。

数据库系统如何来确认哪些数据需要redo或undo呢？那就需要⼀个检查点（checkpoint），在系统中⼀般有⼀个表或⼀个控制⽂件来记录检查点，⽇志是按顺序⼀直写下去的，检查点设置后，只需要⽐对检查点之后的数据就可以了。

　⼆：undo⽇志 1.概述 ⽇志是⽇志记录的⼀个序列。

在多事务的数据库系统中，每个事务有若⼲个操作步骤。

每个⽇志记录记载有关某个事务已做的某些情况。

⼏个事务的⾏为可以是“交错的”，因此可能是⼀个事务的某个步骤被执⾏，并且其效果被记录到⽇志中，接着执⾏另外⼀个事务的某个步骤并记⼊⽇志，接着可能接着做第⼀事务的下⼀个步骤，也可能执⾏另外⼀个事务的某个步骤。

REDO LOG 与 UNDO LOG这两个概念的区别--转载转自：[url]/jonescheng/archive/2008/05/08/1189063.ht ml[/url]redo log 重做日志/undo log 撤消日志重做日志：每当有操作执行前，将数据真正更改时，先前相关操作写入重做日志。

这样当断电，或者一些意外，导致后续任务无法完成时，系统恢复后，可以继续完成这些更改撤消日志：当一些更改在执行一半时，发生意外，而无法完成，则可以根据撤消日志恢复到更改之前的壮态网上找到一些解说：以便以后自己参考有两个概念：前滚与回退比如某一时刻数据库DOWN机了，有两个事务，一个事务已经提交，另一个事务正在处理数据库重启的时候就要根据日志进行前滚及回退，把已提交事务的更改写到数据文件，未提交事务的更改恢复到事务开始前的状态。

redo--> undo-->datafileinsert一条记录时, 表跟undo的信息都会放进 redo 中, 在commit 或之前, redo 的信息会放进硬盘上. 故障时, redo 便可恢复那些已经commit 了的数据.redo->每次操作都先记录到redo日志中，当出现实例故障（像断电），导致数据未能更新到数据文件，则数据库重启时须redo，重新把数据更新到数据文件undo->记录更改前的一份copy，但你系统rollback时，把这份copy重新覆盖到原来的数据redo->记录所有操作，用于恢复（redo records all the database transaction used for recovery）undo->记录所有的前印象，用于回滚（undo is used to store uncommited data infor used for rollback）redo->已递交的事务,实例恢复时要写到数据文件去的undo->未递交的事务.redo的原因是：每次commit时，将数据的修改立即写到online redo中，但是并不一定同时将该数据的修改写到数据文件中。

redo和undo区别讨论英⽂解释：名词：两种流程，redo重做流程，undo撤销还原流程；或则是redo⽇志与undo段的简称动词：redo即重做，undo即撤销还原。

翻译有时候为了简单，常把动词和名称混⽤。

不同场景不同的使⽤。

1.redo记录了什么：redo即redo⽇志，记录数据库变化的⽇志（区别我们常见的简单的⽂本⽇志，redo⽇志⾥⾯记录的都是数据啊，表数据啊等等压缩处理，但也很⼤）。

只要你修改了数据块那么就会记录redo信息，当然nologging除外了。

修改的数据块包括：表所在数据块（表数据块），索引所在数据块（索引数据块），以及undo段所在数据块（undo数据块）！！2.undo记录了什么：undo即undo段，是指数据库为了保持读⼀致性，存储历史数据在⼀个位置。

为什么要保持读⼀致性？⽐如有两个⽤户访问数据库，当然并发罗。

A是更改，B是查询。

--A更改还没有提交，B查询的话，数据肯定为历史数据，这个历史数据就是来源于UNDO段，--A更改未提交，需要回滚rollback，回滚rollback的数据也来⾄于UNDO段。

结论：为了并发时读⼀致性成功，那么DML操作，肯定先写UNDO段。

3.前滚与回滚：--⽅向相对性：前滚，是指从“以前正常点”往前，⼀直到崩溃点回滚，是指从“崩溃点”往后，⼀直到数据⼀致性（因为前滚操作后，由于事务未提交的数据也写⼊了“表数据块”，所以要⽤Undo数据块进⾏覆盖--详细解释：前滚：当实例崩溃时，可以使⽤redo从以前正常的点前滚到崩溃点。

（前滚从⼀致性检查点，“即当时检查过所有的SCN是全部⼀致的时间点”，⼀直往前滚到崩溃的时间点）。

当数据库回到⼀致性检查点时，相当于之后什么都没有发⽣过，数据全被清空了。

（穿越了！O(∩_∩)O~）数据库只好根据redo模拟⼈的操作，使⽤redo⾥的信息重做（use redo log to redo)，构造undo块，表块，索引块等。

undertow access 日志-概述说明以及解释1.引言1.1 概述Undertow是一个轻量级，灵活的Web服务器，被广泛应用于Java 应用程序的开发和部署。

在Undertow中，access日志是一种记录每个请求的详细信息的功能，包括请求方法，请求路径，响应状态码等。

这些access日志对于监控和分析应用程序的性能以及诊断问题非常重要。

在本文中，我们将深入探讨undertow access 日志的定义、重要性以及如何记录这些日志。

通过了解undertow access 日志的作用和记录方法，我们可以更好地优化应用程序的性能，改进用户体验，并及时发现和解决潜在的问题。

Undertow access 日志不仅是开发人员的利器，也是运维人员的重要工具，有助于提升整个应用程序的可靠性和稳定性。

1.2 文章结构:本文主要由三个部分组成: 引言、正文和结论。

- 引言部分将概述undertow access 日志的概念，介绍文章的结构及目的，为读者提供整体认识和预期。

- 正文部分将详细介绍什么是undertow access 日志，其重要性以及如何记录undertow access 日志，帮助读者深入了解该主题。

- 结论部分将对undertow access 日志的作用进行总结，展望未来发展，最后结束文章。

通过这样的结构，读者可以系统地了解undertow access 日志，包括其定义、意义和实践应用，为他们的学习和工作提供有益指导。

1.3 目的本文的目的是为读者介绍undertow access日志的重要性和记录方法。

通过本文的阐述，读者可以了解到undertow access日志的作用以及如何在实际项目中记录和管理这些日志信息。

同时，本文也将探讨未来undertow access日志可能的发展方向，为读者提供更深入的思考和展望。

希望本文能够帮助读者更好地理解和利用undertow access日志，提升对项目运行状态的监控和管理能力。

MySQL中的undo⽇志概念介绍：我们知道，MySQL中的redo⽇志记录了事务的⾏为，在服务器宕机的时候，可以通过重做事务来达到恢复数据的⽬的，然⽽，有的时候，事务还有回滚的需求，也就是说，我们需要知道某条在变成当前情况之前的样⼦，这种情况下，undo⽇志就派上⽤场了。

也就是说，undo⽇志是为了将数据恢复到修改之前的样⼦，因此在对数据库进⾏修改的时候，我们需要知道，这个过程中会产⽣redo⽇志和undo⽇志。

存储位置：我们还知道，redo⽇志⼀般情况下放在redo⽇志⽂件中，也就是常说的ib_log中，⽽undo⽇志存放在数据库内部的⼀个"段"中，这个概念，我们在8⽉21号的⽂章中有讲过，忘记的同学可以回去看看，undo⽇志的段位于共享表空间内。

回滚操作：现在，我们已经知道了undo的概念，其实就是共享表空间中的⼀块区域，它的主要作⽤是将事务恢复到执⾏修改之前的样⼦，但是，恢复的情况⼀般分为两种，⼀种是逻辑恢复，⼀种是物理恢复，这⾥需要⾮常强调的是，undo的恢复是逻辑恢复，也就是说，如果你插⼊了100w条数据，导致innodb分配了⼀个新的数据页来存储这些数据，那么在事务进⾏回滚的时候，undo的功能并不是回收这个数据页，⽽是将这些insert的操作，改变成delete的操作从⽽执⾏回滚。

在这个过程中，共享表空间的⼤⼩并不会发⽣改变。

除此之外，undo⽇志会将delete操作转化为insert操作，update操作转化为反向的update操作。

删除⽅式：还有⼀点需要注意，事务共享表空间中写⼊undo⽇志的过程同样需要写⼊redo⽇志，事务⼀旦提交，也就意味着事务的持久性⽣效，那么undo⽇志则不被需要，但是innodb并不会把这个undo⽇志直接删除，⽽是放在⼀个undo⽇志的链表中，到底什么时候删除取决于mysql的purge线程，这样做是为了避免其他的事务需要通过undo⽇志来得到这条记录之前的版本。

⾯试：mysql中binlog、undolog、redolog三种⽇志的区别请讲下mysql中binlog、undolog、redolog三种⽇志的区别分析：mysql中这三种⽇志很常见，也是⾯试中涉及⽐较多的⽅⾯，要理解清楚这三种⽇志的定位及区别；回答要点：主要从以下⼏点去考虑1、三种⽇志的作⽤分别是什么；2、三种⽇志解决的问题；3、三种⽇志分别是什么时间写⼊的；bin log、redo log、undo log三种⽇志属于不同级别的⽇志，按照mysql的划分可以分为服务层和引擎层两⼤层，bin log是在服务层实现的；redo log、undo log是在引擎层实现的，且是innodb引擎独有的，主要和事务相关。

bin logbin log中记录的是整个mysql数据库的操作内容，对所有的引擎都适⽤，包括执⾏的DDL、DML，可以⽤来进⾏数据库的恢复及复制。

bin log有三种形式：statement、row、mixed，statement是基于语句的，也就是执⾏的sql语句，该种形式的⽂件⽐较⼩，例，update t1 set age='24' where name like '%王%'，这样⼀条语句，在statement下就会记录这样⼀条sql；row是基于数据⾏的，会记录变化的所有数据，⼀般⽂件较⼤。

例，update t1 set age='24' where name like '%王%'，这条语句，在row的形式下，则会记录该条sql影响的所有数据记录；mixed是混合格式，是statement和row的组合；redo logredo log中记录的是要更新的数据，⽐如⼀条数据已提交成功，并不会⽴即同步到磁盘，⽽是先记录到redo log中，等待合适的时机再刷盘，为了实现事务的持久性undo logundo log中记录的是当前操作中的相反操作，⼀条insert语句在undo log中会对应⼀条delete语句，update语句会在undo log中对应相反的update语句，在事务回滚时会⽤到undo log，实现事务的原⼦性，同时会⽤在MVCC中，undo中会有⼀条记录的多个版本，⽤在快照读中；上⾯⼤体讲了三种⽇志的作⽤及背景和解决的问题，有个问题⼀直困扰着我，那就是在执⾏⼀条sql时，这三种⽇志是什么时间写⼊的。

Undo⽇志⽂件的产⽣和使⽤Undo ⽇志⽐如A有200块钱， B有50 块钱，现在A要给B转100块” 。

(1) 开始事务 T1 （假设T1是个事务的内部编号）(2) A余额 = A余额 -100(3) B余额 = B余额 + 100(4) 提交事务 T1会对此事务记录Undo的⽇志⽂件，记录下事务开始之前的他俩账号余额：[开始事务 T1][事务T1, A原有余额，200][事务T1, B原有余额，50]如果事务执⾏到⼀半挂了，数据库重启以后我就根据undo的⽇志⽂件来恢复。

例⼦：如果第三步还没执⾏完就断电了，数据库重启以后就需要根据undo⽇志复原，要是系统恢复的过程中⼜断电了，下次重启再次恢复，此操作拥有幂等性，重复多少次都没有问题。

如何判断哪些事务需要恢复恢复之后需要在⽇志⽂件中加上⼀⾏ [回滚事务 T1] ，这样下⼀次恢复就不⽤再考虑T1这个事务了。

[开始事务 T1][事务T1, A原有余额，200][事务T1, B原有余额，50][提交事务 T1]Undo⽇志⽂件中不仅仅只有余额，事务的开始和结束也会记录，如果我在⽇志⽂件中看到了[提交事务 T1], 或者 [回滚事务 T1], 就表⽰此事务已经结束，不⽤再去理会它了，更不⽤去恢复。

如果我只看到 [开始事务 T1], ⽽找不到提交或回滚，那就得恢复。

⽇志从缓冲区写⼊磁盘的时机两条规则：1. 在最新余额写⼊硬盘之前，⼀定要先把相关的Undo⽇志记录写⼊硬盘。

例如[事务T1, A原有余额，200] ⼀定要在A的新余额=100写⼊硬盘之前写⼊。

2. [提交事务 T1] 这样的Undo⽇志记录⼀定要在所有的新余额写⼊硬盘之后再写⼊。

操作数据缓冲区Undo⽇志缓冲区1开始事务T1开始事务T12 A余额 = A余额 -100A新余额：100事务T1，A原有余额，2003把undo⽇志缓冲区内容写⼊磁盘ps：此步骤会清空undo⽇志缓冲区4把A新余额写⼊磁盘5B余额 = B余额 + 100B新余额：1506把undo⽇志缓冲区内容写⼊磁盘7把B新余额写⼊磁盘8提交事务T1提交事务T19把undo⽇志缓冲区内容写⼊磁盘情况⼀：如果系统在第4步和第5步之间崩溃，A的余额写⼊了硬盘，但是B的还没写⼊， Undo⽇志看起来是这样的：[开始事务 T1][事务T1, A原有余额，200]由于找不到事务结束的⽇志，进⾏恢复操作，把A的原有余额给恢复了。

MySQLdump之single-transaction详解MySQLdump之single-transaction详解single-transaction开启general log选项1. 查看⽬前general log的情况mysql> show variables like '%general_log%';+------------------+--------------------------------------------+| Variable_name | Value |+------------------+--------------------------------------------+| general_log | OFF || general_log_file | /data/mysqldata/3306/general_statement.log |+------------------+--------------------------------------------+2 rows in set (0.00 sec)2. 开启general log的选项mysql> set global general_log=on;3. 使⽤mysqldump命令:。

[mysql@racnode1 ~]$ /usr/local/mysql/bin/mysqldump -uroot -p'zsd@7101' -S /data/mysqldata/3306/mysql.sock --single-transaction --default-character-set=utf8 zdemo student > /tmp/studentbackup.sql 其中使⽤了两个参数--single-transaction 此选项会将隔离级别设置为：REPEATABLE READ。

MySQL死锁⽇志分析------------------------LATEST DETECTED DEADLOCK------------------------2017-09-0611:58:16 7ff35f5dd700*** (1) TRANSACTION:TRANSACTION 182335752, ACTIVE 0 sec insertingmysql tables in use 1, locked 1LOCK WAIT 11lock struct(s), heap size 1184, 2 row lock(s), undo log entries 15MySQL thread id 12032077, OS thread handle 0x7ff35ebf6700, query id 19641826510.40.191.57 RW_bok_db updateINSERT INTO bok_task( order_id ...*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 300 page no 5480 n bits 552 index `order_id_un` of table `bok_db`.`bok_task`trx id 182335752 lock_mode X insert intention waiting*** (2) TRANSACTION:TRANSACTION 182335756, ACTIVE 0 sec insertingmysql tables in use 1, locked 111lock struct(s), heap size 1184, 2 row lock(s), undo log entries 15MySQL thread id 12032049, OS thread handle 0x7ff35f5dd700, query id 19641826810.40.189.132 RW_bok_db updateINSERT INTO bok_task( order_id ...*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 300 page no 5480 n bits 552 index `order_id_un` of table `bok_db`.`bok_task`trx id 182335756 lock_mode X*** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 300 page no 5480 n bits 552 index `order_id_un` of table `bok_db`.`bok_task`trx id 182335756 lock_mode X insert intention waiting*** WE ROLL BACK TRANSACTION (2)⽇志中列出了死锁发⽣的时间，以及导致死锁的事务信息（只显⽰两个事务，如果由多个事务导致的死锁也只显⽰两个），并显⽰出每个事务正在执⾏的SQL 语句、等待的锁以及持有的锁信息等。