Mysql中的Redo log日志和binlog日志的详情工作

主要是讲解Redo log 和 binlog实现更新日志的时候

MySql在更新操作时引入“两阶段提交”的必要性

1我们都知道Mysql中是有很多日志的，今天要说的是Redo log（重做日志）和 binlog（二进制日志）

1. Redo log (重做日志):

• Redo log 是用于恢复和崩溃恢复的关键组件，它记录了数据库引擎对于已经提交的操作所执行的物理更改。
• 当数据库发生故障或崩溃时，通过重做日志可以将已提交的更改重新应用到数据库中，从而恢复数据库的一致性。
• Redo log 是一个循环写入的日志文件，它记录了数据页的物理修改操作，而不是逻辑操作。

1. Binlog (二进制日志):

• Binlog 是用于复制和恢复的日志，它记录了数据库的逻辑操作。
• Binlog 记录了对数据库执行的所有更改操作，如插入、更新和删除操作，以及相关的元数据信息。
• Binlog 可以用于实现数据库的主从复制，其中主数据库将其产生的 Binlog 日志发送给从数据库，从数据库根据这些日志进行数据的复制和同步。
• Binlog 也可以用于数据恢复和回滚操作。通过读取 Binlog 中的操作记录，可以还原数据库到特定的时间点或指定的操作。

这两个日志一同使用可以实现很多必要的功能

故障恢复：

当数据库发生故障或崩溃时，Redo log 能够起到关键的作用。通过 Redo log 中记录的已提交事务的物理更改，数据库可以在恢复过程中重新应用这些更改，从而将数据库还原到崩溃前的一致性状态。

数据复制（主从复制）：

Binlog 在主从复制中扮演重要角色。主数据库生成 Binlog 日志，从数据库通过读取主数据库的 Binlog 日志来复制主数据库的数据和操作。这种复制机制允许从数据库保持与主数据库同步，并可以用于负载均衡、备份和高可用性。

数据恢复：

Redo log 和 Binlog 都可以用于数据恢复。通过 Redo log 和 Binlog 中记录的操作，可以还原数据库到特定的时间点或指定的操作。这对于误操作、数据损坏或恢复到历史状态等情况下的数据恢复非常有用。

数据备份：

Binlog 可以用于增量备份，通过定期备份 Binlog 日志，可以将这些日志应用到之前的完整备份上，以恢复到备份后的任何时间点。

大致理解一下SQL执行一条更新语句的流程

• 

1. 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

关于最后三步就是我们所说的两阶段提交，把redolog差写成了两个步骤：prepare和commit

一条SQL语句更新的时候肯定是要同时更新日志的，所以这两个日志也会伴随着更新。他们是运行在事务中的，那么为什么Redo log 在使用的时候要分成两个状态：prapare和commit状态，这两个状态也就是两阶段提交的意思，然后在两个状态中去写binlog日志。今天分析一下，为什么Mysql要这样做（把redo log分成两步，然后把binlog日志放到prepare和commit之间），而不是在一个是个事务中，依次去更新那两个日志。

redo log 和 binlog 的分别

redo log 是引擎层的日志（负责存储相关的事），binlog是在Server层，主要做MySQL服务那个层面的事情。redo log就像一个缓冲区，可以让当更新操作的时候先放redo log中，等系统不忙的时候或redo log 满了的时候再写到磁盘中，redo log的大小是固定的。·这样也可以保证，即使中途数据库重启，也可以依照redo log把未完成写入磁盘的内容完成更新。这个能力叫做crash-safe。

redo log 是InnoDB引擎特有的，而Binlog是MySQL的Server层实现的，所有引擎都可以使用。

binlog会用“追加写”的形式记录所有的逻辑操作，所以binlog文件写到一定大小会切换到下一个，并不会覆盖以前的日志。

两阶段提交是为了让两份日志之间的逻辑一致。

如果不是两阶段提交，无论是先写完 redo log 再写 binlog，或者采用反过来的顺序。在两个中间MySQL进程异常重启，都会发生字段的值与原库的值不同。

不只是误操作后会恢复数据，当需要扩容的时候：多搭建备库来增加系统的读能力的时候，都需要全量备份加上应用binlog实现，如果出现数据库状态“不一致”就会导致线上出现主从数据库不一致的情况。

如果在两阶段中间发生了crash怎么情况？

如果时刻A的话，binlog都没写，redo log 不完整，所以直接事务回滚

如果时刻B的话，先判断binlog是否完整：一个事务的 binlog 是有完整格式的：

• statement 格式的 binlog，最后会有 COMMIT；
• row 格式的 binlog，最后会有一个 XID event。

完整了那就补充redo log，然后恢复数据，如果binlog不完整，那就事务回滚。

它们有一个共同的数据字段，叫 XID。崩溃恢复的时候，会按顺序扫描 redo log：

• 如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
• 如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。

我们可以查看binlog是否完整，却还是把redo log分为两阶段是因为redo log是在事务中的内容，如果不分两个阶段的话，完成redo log 事务就不能再回滚了，这个时候binlog还没写完就重启数据库，binlog中没有这个事务的记录，InnoDB又回滚不了，两个日志不能够同时更新，数据和binlog日志就又不一致了。

redo log存储的是数据页的更新细节，binlog是更新内容。（比如redo log 是存储的将员工ID为101的工资字段的值从5000修改为6000。此时Binlog记录的是将员工ID为101的工资字段更新为6000。）binlog无法实现崩溃恢复，redo log 没法实现归档，因为它是循环写。而且mysql系统还有很多其他地方都依赖于binlog。

两个日志有相似的功能，也有相异的，所以两个日志都要存在，所以要想同时发挥作用，两阶段提交必不可少。