【实现】mysql undo+redo+binlog

rt

数据库事务开始之前，会将要修改的记录存放到UNdo日志里，当事务回滚时或数据库崩溃时，可以利用undo日志撤销未提交事务对数据库产生的影响。

逻辑日志，记录一个过程，提交后不会删除。delete insert

 

采用段的方式管理和记录。在innnodb数据文件中包含一种rollback segment回滚段，

内部包含1024个undo log segment。

 show variables like "%innodb_undo%";

 

作用：

• 实现事务原子性

　　事务处理过程中，如果出现了错误或者用户执行了rollback语句，mysql可以利用undoLog 中的备份将数据恢复到事务开始前的状态。

• 实现多版本并发控制MVCC 

　　　事务未提交之前，undolog 保存了未提交之前的版本数据，undo log中的数据可作为数据旧版本快照供其他并发食物进行快照读。

事务A手动开启事务，执行更新操作，首先会把更新命中的数据备份到undo Buffer中。事务B手动开启事务，执行查询操作，会读取undi日志数据返回，进行快照读

 

redo log

事务中修改的任何数据，将最新的数据备份存储的位置，被称为重做日志

随着事务操作的执行，就会生成redo log，在事务提交时会将产生redo log写入log buffer，并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入到磁盘之后，redolog的使命也就完成了，Redo log 占用的空间就可以重用（被覆盖写入）。

作用：为了实现事务的持久性。防止在发生故障的时间点，尚有脏页为写入表的IBD文件中，在重启MYSQL服务的时候，根据RedoLog进行重做，从而达到事务的未入磁盘数据进行持久化这一特性。

redoLog 是顺序写 同步？ 

其实不然，参考https://blog.csdn.net/m0_37264516/article/details/99480237

用的还是非同步的io。只保证刷到页告诉缓存，优势在于，顺序写，写之前的查 缓存命中率高

顺序循环写的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。

Binlog

 不是innodb独有，是mysql server自己的日志。

主从复制：在主库中开启，主库就可以把binlog传递给从库，从库拿到binlog后实现数据恢复达到主从数据一致性。

数据恢复：通过mysqlbinlog工具来恢复数据。

 文件结构：

 

binlog和redlog区别

redolog 是属于innodb，binlog是属于mysql server自带功能。

redo log属于物理日志，记录该数据页更新状态内容，binlog是逻辑日志，记录更新过程

redo log日志是循环写，日志空间大小是固定。binlog是追加写入， 写完一个写下一个，不回覆盖使用。

redo log作为服务期异常宕机后事务数据自动恢复使用。binlog可以作为主从复制和数据恢复使用。binlog没有自动crash-safe功能