1.Redo日志—innodb存储引擎的日志文件
- 当发生数据修改的时候,innodb引擎会先将记录写到redo log中, 并更新内存,此时更新就算是完成了,同时innodb引擎会在合适 的时机将记录操作到磁盘中
- Redolog是固定大小的,是循环写的过程
- 有了redolog之后,innodb就可以保证即使数据库发生异常重启,
之前的记录也不会丢失,叫做crash-safe
既然要避免io,为什么写redo log的时候不会造成io的问题?
内存刷到磁盘2.Undo log
- Undo Log是为了实现事务的原子性,在MySQL数据库InnoDB存储引擎中, 还用Undo Log来实现多版本并发控制(简称:MVCC)
- 在操作任何数据之前,首先将数据备份到一个地方(这个存储数据备份的地方 称为Undo Log)。然后进行数据的修改。如果出现了错误或者用户执行了 ROLLBACK语句,系统可以利用Undo Log中的备份将数据恢复到事务开始之 前的状态
-
注意:undo log是逻辑日志,可以理解为:
– 当delete一条记录时,undo log中会记录一条对应的insert记录
– 当insert一条记录时,undo log中会记录一条对应的delete记录
– 当update一条记录时,它记录一条对应相反的update记录
3.binlog—服务端的日志文件
Binlog是server层的日志,主要做mysql功能层面的事情
- 与redo日志的区别:
- redo是innodb独有的,binlog是所有引擎都可以使用的
- redo是物理日志,记录的是在某个数据页上做了什么修改,binlog是逻
辑日志,记录的是这个语句的原始逻辑 - redo是循环写的,空间会用完,binlog是可以追加写的,不会覆盖之前
的日志信息,Binlog中会记录所有的逻辑,并且采用追加写的方式
- 一般在企业中数据库会有备份系统,可以定期执行备份,备份的
周期可以自己设置 - 恢复数据的过程:
1、找到最近一次的全量备份数据
2、从备份的时间点开始,将备份的binlog取出来,重放到要恢复的那个时
刻
数据更新的流程
数据更新执行流程:
1、执行器先从引擎中找到数据,如果在内存中直接返回,如果不在内存中,查 询后返回
2、执行器拿到数据之后会先修改数据, 然后调用引擎接口重新吸入数据
3、引擎将数据更新到内存,同时写数据 到redo中,此时处于prepare阶段,并通 知执行器执行完成,随时可以操作
4、执行器生成这个操作的binlog
5、执行器调用引擎的事务提交接口,引 擎把刚刚写完的redo改成commit状态, 更新完成
(3,4,5,保证redoLog和binLog的数据一致性)
Redo log的两阶段提交
- 若先写redo log后写binlog:假设在redo log写完,binlog还没有写完的时候,MySQL进程 异常重启。由于我们前面说过的,redo log写完之后,系统即使崩溃,仍然能够把数据恢复 回来,所以恢复后这一行c的值是1。但是由于binlog没写完就crash了,这时候binlog里面 就没有记录这个语句。因此,之后备份日志的时候,存起来的binlog里面就没有这条语句。 然后你会发现,如果需要用这个binlog来恢复临时库的话,由于这个语句的binlog丢失,这 个临时库就会少了这一次更新,恢复出来的这一行c的值就是0,与原库的值不同。
- 若先写binlog后写redo log:如果在binlog写完之后crash,由于redo log还没写,崩溃恢复 以后这个事务无效,所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个 日志。所以,在之后用binlog来恢复的时候就多了一个事务出来,恢复出来的这一行c的值 就是1,与原库的值不同。
上面2中方式都会导致数据的不一致。
网友评论