更新语句涉及的模块:
连接器建立连接、
分析器解析语句要做什么、
优化器得出怎么做,
执行器调用存储器执行命令,
redo log:重做日志,
bin log:归档日志
1、redo log[存储引擎有的日志]
当业务繁忙时,执行一次更新语句 要到库表中若干个记录中查询要更新的记录,再执行更新操作,整个过程的IO成本,查找成本都很高。
所以mysql这样做:
当有一条记录要更新时,InnoDB先将记录写到 redo log 中,并更新内存,此时更新就算完成,当系统空闲时,InnoDB会将更新写进磁盘。
write pos 是当前写入磁盘的位置,写到 3后会回到0,这样循环下去。
checkpoint 是当前 清除记录的位置,当 write pos 追到 check point 时,表示,日志满了,此时不能执行新的更新操作,得停下来清楚一些更新日志。
有了 redo log, InnoDB保证了即使数据库发送异常,之前提交的记录也不会丢失,这个称为 crash-safe
2、redo log 和 binlog区别
- redo log 是InnoDB引擎特有的,binlog是mysql server层实现,所以存储引擎都可以使用。
- redo log是物理日志,记录了某个数据有什么修改
binlog 是逻辑日志,记录这个语句的原始逻辑,如:给ID=2的c字段+1 - redo log 是循环写的,空间固定会用完,
binlog 是追加写的,写到一定大写后会切换到下一个,不会覆盖以前的日志。 - redo log 有 crash-safe的能力,binlog则没有
3、更新语句的执行流程
update T set c=c+1 where id = 2
1、执行器,通过引擎 获取 id = 2 的记录,如果内存中有直接返回,没有从磁盘中读取再写入内存后返回
2、将记录 c+1后,得到新数据,再调用引擎接口写入这一行新数据。
3、引擎将新数据 更新到内存和redo log ,此时 redo log状态为 prepare,然后告知执行器完成了,随时提交事务。
4、执行器生成操作的 binlog ,并写入磁盘
5、执行器调用引擎提交事务的接口,将 redo log的状态改为 commit ,更新完成。
4、怎么把数据库恢复到半月内的任意一秒
binlog是采用追加式 记录所有的逻辑操作,并且系统会做整库的备份。
- 将最近的全量备份恢复到临时库中
- 从备份中 按照时间依次取出 binlog,找到要恢复的那一时刻的 binlog日志
这样临时库和要恢复的库一样了,把表数据从临时库取出来,按需要恢复
5、redo log为什么两个阶段提交
将 redo log 的写入拆成了两个步骤:prepare 和 commit:是为了 让两份日志之间的逻辑一致。
如果不是两个阶段提交的话
-
先写 redo log 再写 binlog :进行更新操作将N从0改成1,写入 redo log后,还没有写 bin log 系统就崩了,这样redo log有 **crash-safe ** 的特性,可以将数据回复过来,恢复数据为1,但是此时更新的操作并没有记录到 bin log,这样如果要恢复到某时刻数据的话,N是等于0的
-
先写 bin log 再写 redo log:当将N改成1后,写入了 bin log,系统崩了,此时没有写入 redo log ,恢复过来的话 N是0,但是 bin log记录了将N改成1的操作,恢复到某时刻时会将N改成1 ,数据不一致
小结
redo log 保证了crash -safe,innodb_flush_log_at_trx_commit设置为1 ,表示每个事务的 redo log会写入磁盘,保证mysql重启 redo log数据不丢失
sync_binlog 设置为1,每个事务 binlog 写入磁盘,保证 bin log数据不丢失
redo log 主要用于 数据库崩溃后的数据恢复
bin log 用于 将数据库恢复到每一时刻 使用