决战圣地玛丽乔亚 Day28 ---Mysql的log相关

Mysql持久性是如何实现的？

redolog：

CRUD操作后更新整个页到buffer pool中，然后在内存修改数据，但是不会马上刷新到磁盘，如果一条操作去刷新一个页会有性能浪费。

redolog说白了就是一个记录数据修改记录的日志，而且它是循环写入固定文件（会用完空间，binlog追加写不会用完），保证了即使机器宕机后，也可以通过redolog来进行数据恢复。

为了保证事务的原子性，也就是说事务操作产生多条redolog，不能一部分执行一部分不执行，所以redolog为了保证原子性也是按照块组织在一起的，然后写入磁盘中。

redolog有自己的buffer， redolog buffer （默认16MB，buffer分很多块，每个事务产生的所有redolog形成一个group）

innodb_flush_log_at_trx_commit：

参数

1.commit时候进行刷盘，如果commit不成功，那么事务执行失败，也就不需要记录redolog，是最保险的策略。

2.commit的时候，只是刷新近os的内核缓冲区，具体的刷盘时机不确定

0.后台线程，每s刷新一次到磁盘中

模拟一次数据库的更新操作：

连接数据库，从buffer pool查询记录是否存在，如果存在直接更新，否则先从磁盘加载到buffer pool

记录redolog，此时redolog是prepare状态

记录该操作的binlog，并把binlog刷盘

提交事务，对redolog提交。

这里提到了binlog，什么是binlog？

binlog主要是记录数据库执行的所有更改操作，包括表结构的更改和数据的更改。用追加写的方式进行，写满了再开一个，仅在事务提交前进行一次binlog的数据写入。、、

Mysql的两阶段提交：

1、如果先写redolog再写binlog

2、先写binlog再写redolog

先写redolog和先写binlog，如果另一个写入失败都会造成主从同步失败的问题。

3、两阶段提交

更改数据（如果断点，binlog和redolog都没有持久化因此数据最终一致）

写redolog（写完后，redolog处于prepare状态，这个状态代表，如果发生宕机断点的情况，检查redolog的状态，如果是prepare的状态下存在binlog，说明正常。如果只有prepare的redolog没有binlog说明异常，直接删除处于prepare状态的redolog）

写binlog（写完后断电，查看redolog和binlog，只有两者都存在并且redolog是prepare状态说明是之前异常导致没有提交，直接提交。否则的话是异常现象，直接删除log即可）

提交事务，commit

undolog：
上面的redolog和binlog保证了事务的持久性，那么undolog就保证了事务的原子性。

Undo log保证了事务的原子性。在对数据库进行修改时，innoDB引擎除了会产生redo log，还会产生undo log。InnoDB实现回滚，靠的是undo log：当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败导致事务需要回滚，就利用undo log中的信息将数据回滚到修改之前的样子。

undolog还有一个特性就是去实现mvcc的多版本并发控制。当用户读取一行记录时，如果这个记录已接被其他事务占用，那么当前事务就可以通过undo读取之前的行版本信息，用来实现非锁定读取，就是“快照读”

好了，over，明天按照时间线的顺序看java部分