MySQL中已经有了Binlog,为啥还要有Redo Log

2023-12-22 17:34:37

参考文章

MySQL中的Binlog和Redo Log虽然都与事务的持久性和可恢复性有关,但它们服务于不同的目的和场景,并且在MySQL的架构中扮演着互补的角色。

  1. Redo Log
    • 目的:Redo Log 主要用于保证InnoDB存储引擎的事务持久性。它确保在系统崩溃的情况下,已经提交的事务不会丢失,这是通过预写日志(Write-Ahead Logging, WAL)机制实现的。
    • 工作方式:Redo Log 记录的是事务对数据页所做的物理修改。当事务提交时,这些修改可能还没有写入磁盘上的数据文件,但Redo Log会确保这些修改被写入日志文件中。
    • 恢复机制:在发生崩溃后,InnoDB可以利用Redo Log来重做(redo)事务的修改,以此恢复到崩溃前的状态。

如果数据库发生崩溃,InnoDB 在重启时会检查 Redo Log。通过 Redo Log,InnoDB 可以重做(redo)在崩溃前已经提交但可能未写入到数据文件中的事务,确保这些事务的修改得到持久化。

  1. Binlog
    • 目的:Binlog 主要用于记录所有修改了数据库数据的SQL语句,以便用于复制和数据恢复。它是MySQL服务器层的功能,与存储引擎无关。
    • 工作方式:Binlog 记录的是逻辑日志,即实际执行的SQL语句或者在RBR模式下记录的行事件。
    • 复制和恢复:Binlog 使得MySQL可以实现主从复制,主服务器上的操作可以通过复制Binlog到从服务器并重放来同步数据。同时,Binlog也可以用于点时间恢复(Point-in-Time Recovery),恢复到特定时间点的数据库状态。

在执行更新语句过程,会记录redo log与binlog两块日志,以基本的事务为单位,redo log在事务执行过程中可以不断写入,而binlog只有在提交事务时才写入,所以redo log与binlog的写入时机不一样。

为什么两者都需要

  • 不同的恢复和复制需求:Redo Log 主要用于崩溃恢复,而Binlog用于数据复制和点时间恢复。
  • 性能和优化:Redo Log 的物理日志对于崩溃恢复来说性能更优,因为它直接关联到数据页的状态。Binlog 的逻辑日志则更适合于复制和审计,因为它记录了实际执行的操作。
  • 隔离存储引擎与服务器层Redo Log 是InnoDB存储引擎特有的,而Binlog 是MySQL服务器层的功能,这种设计使得Binlog可以用于多种存储引擎。

总之,Redo Log 和 Binlog 在MySQL中共同工作,以确保数据的安全性、持久性和一致性,同时提供灵活的数据恢复和复制选项。

MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性,使用 undo log(回滚日志) 来保证事务的原子性。MySQL数据库的数据备份、主备、主主、主从都离不开binlog,需要依靠binlog来同步数据,保证数据一致性。


文章来源:https://blog.csdn.net/qq_41638851/article/details/135156062
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。