1.redo log
- 记录数据修改后的值,对事务持久性的保障,让数据库拥有崩溃恢复能力。
- 修改操作先对Buffer Pool的数据进行更新并且记录在redo log buffer中,如下图所示,redo log buffer 然后在刷盘到了硬盘中的redo log中。
- 上面提高了redo log buffer会进行刷盘,那刷盘的时机呢?InnoDB为redo log刷盘提高了innodb_flush_log_at_trx_commit 参数,支持三种策略。默认值为1.
0 :设置为 0 的时候,表示每次事务提交时不进行刷盘操作
1 :设置为 1 的时候,表示每次事务提交时都将进行刷盘操作(默认值)
2 :设置为 2 的时候,表示每次事务提交时都只把 redo log buffer 内容写入 page cache- 策略为0的时候:
> - 策略为1的时候:
- 策略为2的时候:
- 磁盘中的redo log不是单个文件,而是以文件组的方式存在的,如下图所示,通过write pos(记录写的位置,一遍写一遍后移)和checkpoint(记录是当前要擦除的位置,也是往后推移)来进行标志读写和清除。
- 存在一个问题,为什么会存在redo log,修改数据直接刷盘就行了?为什么还要存在redo log?因为直接刷盘是按照整个缓存页进行刷盘的,性能十分差,并且修改的数据位置也比较少,用redo log记录去刷盘,性能远远超过直接刷页。
2.binlog
- 只要发生表数据的更新就会有binlog日志,binlog会记录所有涉及数据的逻辑操作,并且是顺序写。
- binlog的作用:MySQL数据库的数据备份、主备、主主、主从都离不开binlog,需要依靠binlog来同步数据,保证数据一致性。
- 记录格式:通过binlog_format参数指定:statement(会根据没一条sql语句进行记录)、row(在对statement中处理不了的now()进行修补,用一个引用来代理)、mixed(前两者的混合)
- 写入机制:先把日志写入binlog cache中,事务提交之后在写入binlog中,如下图所示,系统是将binlog cache在写入文件系统page cache中,速度比较快,然后由fsyn持久化到次哦按中。
- write和fsync的时机,可以由参数sync_binlog控制,默认是0。为0的时候,表示每次提交事务都只write,由系统自行判断什么时候执行fsync。
- 虽然性能得到提升,但是机器宕机,page cache里面的 binlog 会丢失。
为了安全起见,可以设置为1,表示每次提交事务都会执行fsync,就如同 redo log 日志刷盘流程 一样。
最后还有一种折中方式,可以设置为N(N>1),表示每次提交事务都write,但累积N个事务后才fsync。
3.两阶段提交
- 作用:为了解决redo log和binlog不一致的问题。
- redo log的写入拆成两个步骤prepare和commit。如下图所示。
- 使用两阶段提交后,写入binlog时发生异常也不会有影响,因为MySQL根据redo log日志恢复数据时,发现redo log还处于prepare阶段,并且没有对应binlog日志,就会回滚该事务。
4.undo log
- 保证了事务的原子性,记录了数据修改之前的值,用于回滚恢复。
5.为啥存在了binlog之后还会存在redo log?
- binlog出现在redo log之前,MySQL5.5版本之前用的是MYISAM存储引擎,不支持数据库崩溃恢复,MySQL而5.5版本只有采用InnoDB存储引擎,redo log具有崩溃恢复的能力。
- binlog是记录逻辑日志,记录修改语句,且采用追加的方式记录全部的数据修改,binlog日志中没有记录哪些数据是已经刷入磁盘中,binlog用来归档。
- redo log是物理日志,记录数据页上面修改了内容,采用循环写的方式,并且redo log中的记录刷入磁盘中就会删除、
6.用简单的话语描述一下redo log和binlog的一致性的解决方案?
- 采用两阶段提交的方式,redo log有prepare和commit两种状态。
- 1.修改语句过来查询缓存池中是否有数据,2.没有数据的话从磁盘加载到缓存池,3.对缓存池中的数据进行修改,4.将修改记录到redo log,此时处于prepare状态,5.执行器生成这个操作的binlog日志并记录在binlog中,5.在把redo log更新为commit状态。6.事务提交完。
- 若处出现在写入binlog出现故障,若是binlog完整,则事务成功,若不完成则需要进行回滚。