【MySQL】MySQL的三种log——binlog、redo log、undo log（一文带你彻底搞 ...

目录
MySQL中的三种log
什么是binlog
 binlog是干啥的
什么是redo log
binlog和redo log
相比各人一定有疑惑，binlog和redo log都是用来“规复”的，他俩究竟有什么区别呢
目的：
数据内容：
写入机遇：
巨细和持久性：
什么是undo log
undo log有什么用
redo log 重做日记（MySQL 存储引擎 InnoDB 的事件日记）
undo log 回滚日记（MySQL 存储引擎 InnoDB 的事件日记）
bin log 归档日记（数据库 Server 层二进制逻辑日记、和什么引擎无关）

---

MySQL中的三种log

 末了写入binLog文件，redo事件状态变动为commit

什么是binlog

binlog实在在日常的开发中听得很多的，由于很多时间数据的更新就依赖着binlog。
举个简单的例子：我们的数据是生存在数据库里边的，现在我们对某个商品的某个字段的内容改了（数据库变动），而用户检索出的来数据是走搜索引擎的。为了让用户可以或许收到最新的数据，我们必要把引擎的数据也改掉。
通俗来讲——数据库的变动，搜索引擎的数据也要变动
于是，我们就会监听binlog的变动，如果binlog有变动了，那我们就必要将变动写到对应的数据源当中。
   什么是binlog
   binlog记载了数据库表布局和表数据变动，比如update、delete、insert、truncate、create。（不会记载select由于select并不会对表举行变动）
   binlog长什么样
    binlog我们可以简单理解为：存储着每条变动的SQL语句
（从下面的图看来看，不止SQL，还有XID「事件Id」等等）

 binlog是干啥的

• MySQL在公司使用的时间往往都是一主多从布局的，从服务器必要与主服务器的数据保持同等，这就是通过binlog来实现的
  
• 数据库的数据被干掉了，我们可以通过binlog来对数据举行规复。
  

由于binlog记载了数据库表的变动，所以我们可以用binlog举行复制（主从复制)和规复数据。

什么是redo log

假设有这样一条SQL

1. update user_table set name='java3y' where id = '3'

复制代码

MySQL实行这条SQL语句，肯定是先把id=3的这条记载查出来，然后将name字段给改掉。这没问题吧？
实际上Mysql的根本存储布局是页(记载都存在页里边)，所以MySQL是先把这条记载所在的页找到，然后把该页加载到内存中，将对应记载举行修改。
现在就可能存在一个问题：如果在内存中把数据改了，还没来得及落磁盘，而此时的数据库挂了怎么办？显然这次更改就丢了。

如果每个哀求都必要将数据立马落磁盘之后，那速率会很慢，MySQL可能也顶不住。所以MySQL是怎么做的呢？
MySQL引入了redo log，内存写完了，然后会写一份redo log，这份redo log记载着这次在某个页上做了什么修改。

 实在写redo log的时间，也会有buffer，是先写buffer，再真正落到磁盘中的。至于从buffer什么时间落磁盘，会有配置供我们配置。

        写redo log也是必要写磁盘的，但它的利益就是顺序IO（我们都知道顺序IO比随机IO快非常多）。
        所以，redo log的存在为了：当我们修改的时间，写完内存了，但数据还没真正写到磁盘的时间。此时我们的数据库挂了，我们可以根据redo log来对数据举行规复。由于redo log是顺序IO，所以写入的速率很快，而且redo log记载的是物理变化（xxxx页做了xxx修改），文件的体积很小，规复速率很快。
binlog和redo log

相比各人一定有疑惑，binlog和redo log都是用来“规复”的，他俩究竟有什么区别呢

主要区别：

• 目的：
  
  
  
  • binlog：binlog主要用于规复数据修改操纵，记载了对数据库举行的全部修改语句，如INSERT、UPDATE、DELETE等。它是用于数据备份、主从复制以及高可用性方案的关键构成部分。
    
  • redo log：redo log用于数据库事件的持久性，记载了对数据库的逻辑变化。它主要用于确保在宕机或瓦解时，可以通过重做日记来重新实行已提交的事件，保证数据的同等性。
    
  
  
• 数据内容：
  
  
  
  • binlog：binlog以文本形式记载SQL语句或SQL语句的逻辑表示。它包含了对数据库的增编削操纵的具体信息，可以用来重放这些操纵。
    
  • redo log：redo log是一个循环的、预分配的固定长度的二进制文件，记载了对数据库页的物理修改操纵。它包含了物理上的页地址、修改前后的数据值等，用于重做被修改的页。
    
  
  
• 写入机遇：
  
  
  
  • binlog：binlog是在事件提交之后才会被写入磁盘，它记载了已经完成的事件。
    
  • redo log：redo log是在事件实行过程中被写入磁盘，这样可以确保事件在提交之前，对数据库的修改已经被记载下来。
    
  
  
• 巨细和持久性：
  
  
  
  • binlog：binlog的巨细是由系统参数binlog_max_size控制的，它可以被删除或轮换。它是非持久性的，即在数据库重启后会被清空，必要依靠备份来举行数据规复。
    
  • redo log：redo log的巨细是固定的，当redo log被写满时，会被清空并重用空间。它是持久性的，即在数据库重启后会被保留，可以确保数据的同等性。
    
  
  

        总体而言，binlog主要用于记载已完成的操纵，以实现数据备份、复制和规复等功能；而redo log主要用于事件的持久性，以确保数据的同等性。它们在日记内容、写入机遇和持久性等方面有所差别，但都是MySQL中重要的日记机制，为数据库的可靠性和可规复性提供了支持。

什么是undo log

undo log有什么用

undo log的两个主要作用——回滚和多版本控制（MVCC）
在数据修改的时间，不但记载了redo log，还记载undo log，如果由于某些原因导致事件失败或回滚了，可以用undo log举行回滚
undo log主要存储的也是逻辑日记，比如我们要insert一条数据了，那undo log会记载的一条对应的delete日记。我们要update一条记载时，它会记载一条对应相反的update记载。
由于undo log存储着修改之前的数据，相当于一个前版本，MVCC实现的是读写不阻塞，读的时间只要返回前一个版本的数据就行了。
redo log 重做日记（MySQL 存储引擎 InnoDB 的事件日记）

        我们知道 MySQL 数据存在磁盘中，每次读写数据需做磁盘 IO，并发场景下性能差。为此 MySQL 引入缓存 Buffer Pool 做优化。其包含磁盘中部分数据页（page）的映射，来缓解数据库的磁盘压力。
        当从数据库读数据时，首先从缓存中读，缓存中没有，则从磁盘读后放入缓存；当向数据库写数据时，先向缓存中写，此时缓存中的数据页数据会变动，该数据页叫脏页，Buffer Pool 中修改完数据后会按照设定的策略再定期刷到磁盘中去，这个过程叫刷脏页。
那么问题来了，如果 Buffer Pool 中修改的数据还没有及时的刷到磁盘，MySQL 宕机重启，就会导致数据丢失，无法保证事件的持久性，怎么办？
        redo log 办理了这个问题。就是说数据库在修改数据时，会把更新记载先写到 redo log 中，再去修改 Buffer Pool 中的数据，当提交事件时，调用 fsync 把 redo log 刷入磁盘。至于缓存中更新的数据文件何时刷入磁盘，则由配景线程异步处置惩罚。
        注意：此时 redo log 的事件状态是 prepare，还未真正提交乐成，要等 bin log 日记写入磁盘完成后才会变为 commit，事件才算真正提交乐成。

redo log 的写入方式？
        redo log 采取巨细固定，循环写入的方式，当写满后，会重新重新开始循环写，类似一个环状。这样设计原因是 redo log 记载的是数据页上的修改，如果 Buffer Pool 中数据页已经刷到磁盘，这些记载就失效了，新日记会将这些失效的记载覆盖擦除。
注意：redo log 满了，在擦除之前，要确保这些要被擦除记载都已经刷到磁盘中了。在擦除旧记载释放新空间期间，不能再接收新的更新哀求，此时 MySQL 性能会降落。因此高并发情况下，公道调解 redo log 巨细很重要。
crash-safe 本事是什么？
        Innodb 引擎有 crash-safe 本事，即事件提交过程中任何阶段，MySQL 宕机重启后都能保证事件的完备性，已提交的数据不会丢失。这种本事是通过redo log保证的，MySQL 宕机重启，系统将主动查抄 redo log，将修改还未写入磁盘的数据从 redo log 规复到 MySQL 中。

undo log 回滚日记（MySQL 存储引擎 InnoDB 的事件日记）

undo log 记载的是数据修改之前的状态，属于逻辑日记，起到回滚的作用，是保证事件原子性的关键。
举个栗子：假如更新 ID=1 记载的 name 字段，name 原始数据为小王，现改 name 为小张，事件实行 update X set name = 小张 where id =1 语句时，先在 undo log 中记载一条相反逻辑的 update X set name = 小王 where id =1 记载，这样当某些原因导致事件失败，就可借助 undo log 将数据回滚到事件实行前的状态。
 
那么问题来了：同一个事件的一条记载被多次修改，难道每次都要把数据修改前的状态写 undo log 吗？
不会，由于 undo log 只记载事件开始前数据的原始版本，当再次对这行数据修改时，产生的修改记载会写到 redo log。undo log 负责回滚，redo log负责前滚。

啥是回滚和前滚？
（1）回滚
未提交的事件，即事件未实行 commit。但事件内修改的脏页中，有一部分已刷盘。此时数据库宕机重启，必要回滚来将先前那部分已经刷盘的脏块从磁盘上打消。
（2）前滚
未完全提交的事件，即事件已经实行 commit，但该事件内修改的脏页中只有一部分数据被刷盘，另一部分还在 buffer pool，此时数据库宕机重启，就要用前滚来将未来得及刷盘的数据从 redo log 中规复出来并刷盘。
bin log 归档日记（数据库 Server 层二进制逻辑日记、和什么引擎无关）

        bin log 记载了用户对数据库全部 sql 操纵（不包含查询语句，由于这类操尴尬刁难数据本身没有修改）。之所以可以称为归档日记，是由于它不会像 redo log 那样循环擦除之前的记载，而是会一直记载日记。一个 bin log 文件默认最大容量1G（可通过 max_binlog_size 参数修改），单个日记超过最大值则会新创建一个文件继承写。
        注意：日记可能是基于事件来记载的，而事件不应该跨文件记载，如果 binlog 日记文件达到了最大值但刚功德务还没有提交，此时则不会创建新文件记载，而是继承增大日记。因此 max_binlog_size 的值和实际的 binlog 文件巨细不一定相当。
经过上述介绍，binlog 主要用就是主从同步和数据库基于时间点的还原。
redo log 与 bin log 的区别？

 什么是 redo log 两阶段提交，为什么要这么做？
        更新内存后引擎层写 redo log 将状态改成 prepare 为提交第一阶段，Server 层写 bin log，将状态改成 commit 为提交第二阶段。 两阶段提交目的是确保 binl og 和 redo log 数据同等性。
如果不是两阶段提交可能会出现什么情况？
1）假设先写 redo log 再写 bin log，即 redo log 没有 prepare 阶段，写完直接置为commit，然后再写 bin log。如果写完 redo log 后还没写完 bin log 数据库宕机了，重启后系统主动用 redo log 规复，此时会造成磁盘上数据页数据比 bin log 上的记载数据多，数据不同等。
2）假设先写 bin log 再写 redo log，如果写完 bin log 没写完 redo log 数据库宕机了，那么 bin log 上的记载就会比磁盘上数据页的记载多一些，下次用 bin log 规复数据，规复后的数据和原来的数据不同等。

描述一下 redo log 容灾规复过程？
如果 redo log 是完备（commit 状态）的，直接用 redo log 规复；
如果 redo log 是预提交 prepare 但不是 commit 状态，此时要去判定 binlog 是否完备，如果完备（commit）那就提交 redo log，再用 redo log 规复，不完备就回滚事件。
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。