引言

在InnoDB中，Redo日志和Undo日志是两个重要的日志组件，它们在保证数据一致性和耐久性方面起到了关键作用.

Redo & Undo

  1. Redo日志（重做日志）：

    • Redo日志是InnoDB引擎中的业务日志，用于记载现已提交的业务对数据库所做的修正操作。它是物理日志，记载的是对数据页的修正。
    • Redo日志的作用是保证数据的耐久性，即使在数据库溃散的情况下也能够康复数据的一致性。当数据库发生溃散时，经过重放Redo日志，能够将已提交的业务的修正操作重新应用到数据页上，然后康复数据的最新状况。
    • Redo日志是顺序写入的，这使得它具有高功能。Redo日志的写入是在业务提交之前完结的，这样能够保证在业务提交后，相关的Redo日志现已耐久化到磁盘上。

  2. Undo日志（吊销日志）：

    • Undo日志是InnoDB引擎中的业务日志，用于记载业务对数据库所做的修正操作的反向操作。它是逻辑日志，记载的是对数据行的逻辑操作。
    • Undo日志的作用是在业务回滚和MVCC（多版别并发控制）中起到关键作用。当业务回滚时，经过Undo日志中的信息，能够将业务对数据库的修正操作吊销，使数据回滚到之前的状况。
    • Undo日志还用于支持读取一致性。当一个业务读取数据时，假如有其他业务正在修正这些数据，InnoDB会依据Undo日志供给的信息，将数据康复到业务启动时的状况，然后保证读取的一致性。

寄存方式

Redo

就如上面所说，Redo日志是一种物理日志，用于记载对数据库进行的修正操作。在InnoDB中，Redo日志以固定巨细的日志文件（通常为64MB）的方式进行寄存。当Redo日志文件被写满时，InnoDB会自动创立新的日志文件，并将新的修正操作记载在新的文件中。这样的循环进程保证了Redo日志的耐久性。

Undo

那么Undo日志呢，它是一种逻辑日志，用于记载业务的回滚操作。在InnoDB中，Undo日志以回滚段（Rollback Segment）的方式进行寄存。每个回滚段由一个或多个Undo日志文件组成，这些文件用于存储业务的回滚信息。当业务需要回滚时，InnoDB会依据Undo日志中的信息进行相应的操作，将数据康复到业务开端之前的状况。

业务的一致性和耐久化存储

在MySQL中，Undo日志和Redo日志是用来完结业务的一致性和耐久化存储的重要组成部分。它们在业务的不同阶段发挥不同的作用，协作工作以保证数据的一致性和耐久性。

下面是Undo日志、Redo日志和业务的协作流程的扼要描绘：

  1. 开端业务：

    • 当一个业务开端时，MySQL会为该业务分配一个唯一的业务ID，并创立一个Undo日志记载，用于存储该业务或许对数据所做的修正。

  2. 履行业务：

    • 在业务履行期间，一切的数据修正操作都会生成对应的Redo日志记载。这些记载包含了被修正的数据的旧值和新值。

  3. 业务提交：

    • 当一个业务提交时，MySQL会将业务的一切Redo日志记载耐久化到磁盘中，以保证业务的修正能够在体系故障后康复。
    • MySQL会将业务的Undo日志记载标记为已提交，表明该业务现已成功完结。

  4. 回滚业务：

    • 假如一个业务需要回滚，MySQL会运用Undo日志记载中的旧值来康复被修正的数据。经过吊销业务的修正，能够将数据康复到业务开端之前的状况。

  5. 溃散康复：

    • 在体系溃散或反常关闭后，MySQL会运用Redo日志记载来康复未耐久化的业务修正。经过重新履行未完结的业务的Redo日志记载，能够将数据康复到溃散前的状况。

经过Undo日志和Redo日志的协作，MySQL能够完结数据的一致性和耐久化存储。Undo日志用于回滚业务的修正，而Redo日志用于重做未耐久化的业务修正。这种机制能够保证在体系故障或反常情况下，数据的一致性得到保证，并且能够经过重新履行Redo日志来康复未完结的业务。

日志重写

日志在InnoDB中会进行重写。重写日志是为了开释现已完结的业务所占用的空间，以便新的业务能够持续写入日志。

InnoDB中的日志重写机制是经过”checkpoint”来触发的。Checkpoint是指将内存中的脏页（现已修正但没有写入磁盘的数据页）刷新到磁盘的进程。当发生Checkpoint时，InnoDB会将现已提交的业务的Redo日志写入磁盘，并且将这些现已写入磁盘的日志空间开释出来，以便后续的业务运用。

具体的重写机遇和策略如下：

  1. 每个业务提交时，其对应的Redo日志都会被写入磁盘。
  2. 当脏页的数量达到必定阈值时，会触发Checkpoint，将这些脏页写入磁盘，并将对应的Redo日志空间开释。
  3. 当数据库关闭时，会进行一次全局的Checkpoint，将一切脏页写入磁盘，并开释相应的Redo日志空间。
  4. 当Redo日志文件被写满时，会创立新的日志文件，并将未写入磁盘的日志写入新的文件，之后旧的日志文件会被重用或删去。

需要注意的是，日志的重写是一个异步的进程，不会影响业务的正常进行。重写日志的频率和机遇会依据体系负载、日志写入速度以及其他因素而有所调整，以平衡功能和耐久性的需求。

在InnoDB存储引擎中，假如不进行日志重写，或许会导致以下问题：

  1. 日志文件空间不足：InnoDB运用两个首要的日志文件，即重做日志文件（Redo log files）。这些日志文件是循环运用的，当日志文件空间用尽时，InnoDB会停止写入新的业务日志，这将导致数据库无法履行新的业务操作。
  2. 数据一致性问题：重做日志记载了对数据库的物理修正操作，它们是用来在数据库溃散或重启后康复数据的关键。假如不进行日志重写，重做日志或许会变得过于巨大，导致康复进程变得缓慢。此外，假如重做日志文件损坏或丢掉，或许无法正确康复数据，然后导致数据一致性问题。
  3. 功能下降：假如重做日志文件变得过大，InnoDB在履行康复操作时或许需要花费更长的时刻。此外，由于需要频繁切换和写入重做日志文件，或许会对功能产生负面影响。

过错日志

在MySQL中，能够经过查看过错日志（error log）来获取日志重写的相关记载。过错日志是MySQL记载体系事情和过错信息的文件，其间包含了各种操作和事情的具体记载，包含日志重写的相关信息。

要查看过错日志，能够依照以下步骤进行操作：

  1. 打开MySQL配置文件（通常是my.cnf或my.ini），找到[mysqld]部分。

  2. 在[mysqld]部分中增加或修正以下行：

    log_error = /path/to/error.log

    将/path/to/error.log替换为你希望保存过错日志的路径和文件名。

  3. 重启MySQL服务，使配置生效。

  4. 在指定的过错日志路径中查找日志文件，运用文本编辑器打开它。

在过错日志中，你能够搜索关键词如”checkpoint”、”redo log”、”log rewrite”等，以找到与日志重写相关的记载。这些记载通常包含有关重写的时刻戳、重写的日志文件名称、重写的巨细等信息。