8.31笔记（innodb和事务的工作流程）

innodb工作流程：
redo log
redo作用：在ACID过程中，实现的是d的持久化作用，对于AC也有相应作用
redo日志位置：：iblogfile0 iblogfile1中
redobuffer：数据页的变化信息+数据页的当前LSN号
LSN：日志序列号，磁盘数据页，内存数据页，redo buffer ,redolog
redo的刷新策略：
commit：刷新当前事务redobuffer到磁盘。
还会顺便将一部分redo buffer 中没有提交的事务日志刷新到磁盘
补充：
redo存储的是事务工作过程中数据页变化，commit会立即写入磁盘（默认）
日志落盘成功commit才成功。
正常流程工作中：
主要工作是提供快速持久化功能。
mysql出现异常时，主要提供前滚功能。（csr）
自动故障恢复。罗盘数据中日志未落盘，但是LSN高于原数据。
redo数据重新保持一致落盘。



事务的工作流程：
事务举例： 
begin; 
update t1 set A=2 where A=1;
commit;

# redo log 重做日志如何应用
1. 用户发起update事务语句，将磁盘数据页（page100,A=1,LSN=1000）加载到内存(buffer_pool)缓冲区。
2. 在内存中发生数据页修改（A=1改成A=2），形成脏页，更改中数据页的变化，记录到redo buffer中，加入1000个字节日志。LSN=1000+1000=2000。
3. 当commit语句执行时，基于WAL机制，等到redo buffer中的日志完全落盘到ib_logfileN中，commit正式完成。
4. ib_logfileN中记录了一条日志。内容：page100数据页变化+LSN=2000。

## 情景： 当此时，redo落地了，数据页没有落地，宕机了。
1. MySQL CR（自动故障恢复）工作模式，启动数据库时，自动检查redo的LSN和数据页LSN。
2. 如果发现redoLSN>数据页的LSN ，加载原始数据页+变化redo指定内存。使用redo重构脏页（前滚）。
3. 如果确认此次事务已经提交（commit标签），立即触发CKPT动作，将脏页刷写到磁盘上。


## 补充一点： 
    MySQL有一种机制，批量刷写redo的机制。会在A事务commit时，顺便将redo buffer中的未提交的redo日志也一并刷到磁盘。
    为了区分不同状态的redo，日志记录时，会标记是否COMMIT。


## redo保证了ACID哪些特性?
主要是D的特性，另外A、C也有间接关联。


# undo log 回滚日志如何应用？
1. 事务发生数据页修改之前，会申请一个undo事务操作，保存事务回滚日志（逆向操作的逻辑日志）。
2. undo写完之后，事务修改数据页头部（会记录DB_TRX_ID+DB_ROLL_PTR），这个信息也会被记录的redo。

情景1： 
当执行rollback命令时。根据数据页的DB_TRX_ID+DB_ROLL_PTR信息，找到undo日志，进行回滚。

情景2：
    begin; 
    update t1 set A=2 where A=1;
    宕机。

假设： undo 有  ， redo没有
启动数据库时，检查redo和数据页的LSN号码。发现是一致的。
所以不需要进行redo的前滚，此时也不需要回滚。undo信息直接被标记为可覆盖状态。

假设：undo 有，redo也有（没有commit标签。）
1. MySQL CR（自动故障恢复）工作模式，启动数据库时，自动检查redo的LSN和数据页LSN。
2. 如果发现redoLSN>数据页的LSN ，加载原始数据页+变化redo指定内存。使用redo重构脏页（前滚）。
3. 如果确认此次事务没有commit标记，立即触发回滚操作，根据DB_TRX_ID+DB_ROLL_PTR信息，找到und回滚日志，实现回滚。
以上流程被称之为InnoDB的核心特性：自动故障恢复（Crash Recovery）。先前滚再回滚，先应用redo再应用undo。