MySQL中的redolog/undolog/binlog

MySQL中逻辑分层简单介绍

下面是MySQL的逻辑分层图：

• 连接层：连接与线程处理，这一层并不是MySQL独有，一般的基于C/S架构的都有类似组件，比如连接处理、授权认证、安全等。
• 服务层：包括缓存查询、解析器、优化器，这一部分是MySQL核心功能，包括解析、优化SQL语句，查询缓存目录，内置函数（日期、时间、加密等函数）的实现。
• 引擎层：负责数据存储，存储引擎的不同，存储方式、数据格式、提取方式等都不相同，这一部分也是很大影响数据存储与提取的性能的；对存储层的抽象。
• 存储层：存储数据，文件系统

redo log、binlog、undo log 区别与作用

redolog和undolog只存在于innodb中，这两个日志在innodb中统称为事务日志。undolog用于回滚，redolog用于前滚

• 前滚：
  事务提交之后，部分数据写入了磁盘，但是还有部分数据存在脏页上，并没有写入磁盘。此时设备宕机，没有写入磁盘的数据丢失。就要依赖redolog来恢复这部分数据
• 回滚：
  事务还未提交，改动并没有完全生效，但是记录已经被修改。此时设备宕机，数据是有问题的，就要依赖undolog回滚改动

bin log

　　归档日志（二进制日志）(Server 层日志)
　　作用：用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。
用于数据库的基于时间点的还原。
　　内容：逻辑格式的日志，记录了数据库表结构和表数据变更，比如update/delete/insert/truncate/create。它不会记录select（因为这没有对表没有进行变更），可以简单认为就是sql语句。
　　binlog 有三种模式：Statement（基于 SQL 语句的复制）、Row（基于行的复制） 以及 Mixed（混合模式）

redo log

　　 重做日志（引擎层日志）

• 作用
  确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。
• 内容
  物理格式的日志，记录的是物理数据页面的修改的信息，其redo log是顺序写入redo log file的物理文件中去的。
• 产生时间：
  事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中
• 释放时间：
  当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）
• 对应的本地物理文件：
  默认情况下，对应的物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2
  innodb_log_group_home_dir 指定日志文件组所在的路径，默认./ ，表示在数据库的数据目录下。
  innodb_log_files_in_group 指定重做日志文件组中文件的数量，默认2
  关于文件的大小和数量，由以下两个参数配置：
  innodb_log_file_size 重做日志文件的大小
  innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认1

undo log

　　回滚日志（引擎层）

• 作用：
  Undo 记录某 数据 被修改 前 的值，可以用来在事务失败时进行rollback，用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
• 内容：
  逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，记录数据修改被修改前的值
• 释放时间
  当事务提交之后，undo log并不能立马被删除,而是会被放到待清理链表中,待判断没有事物用到该版本的信息时才可以清理相应undolog