mysql的几种日志工作原理

mysql的几种日志工作原理

redo log

InnoDB引擎层日志，属于物理日志，从5.5.5版本开始加入，记录每次操作的行为，用于宕机恢复。它的空间是固定的， 所以会用完。

binlog

server层日志，采用增量写入方式，主要用于备份数据库或恢复数据库

undo log

回滚日志，用于事务提交失败回滚或其他错误回滚。

redo log和binlog的两阶段提交：

在update操作中，server层的执行器先找引擎层，用查询操作找到要修改的数据，然后用行锁锁定这一行数据（mysql8.0之前可以不调用执行器，先从内存缓存中取数据，如果没找到再找引擎层。8.0之后删除了内存缓存不会有这一步)。
然后
1.准备好redo log， redo log 处于 prepare 状态。
2.执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
3.执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。
当在2之前崩溃时
重启恢复：后发现没有commit，回滚。备份恢复：没有binlog 。一致
当在3之前崩溃时
重启恢复：虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。备份：有binlog. 一致

我们假象没有这两个阶段提交，会有什么后果?
第一步直接提交redo log，写数据，第二部生成bin log ，完成更新操作。
如果服务在第一步后宕机了，那么数据被成功写入，而bin log中不存在对此次操作的记录，在主从同步或者是恢复数据库时就会丢失这一条数据。数据丢失很严重的大兄嘚，所以需要两段提交。