- 简单来说,如果只是读操作的话,以上这幅图就够了,但是如果是写操作的话,就涉及到缓存和两段式提交了
两种日志
redo log
- 当一条数据更新时,innordb(特有的)会将记录先写到redo-log里面,并更新到内存里(这时候已经算是完成了更新),在找个空闲的时间把记录保存到磁盘中.
- redo-log大小是固定的.,然后分成几份文件,连起来 ,从头写,写到结尾,再把开头一部分删掉,接着写
- write ps是当前记录的位置,
- check point是清除的位置,两者之间的就是空白可以写的位置,每次清除数据之前都要先吧数据写到磁盘中,
- 如果write pos追上check point的位置就需要停下来,清理一下,再继续写(有顺序)
- 有了这个redo-log,即使服务器异常重启了.也能保证数据不会丢失,这个被称为crash-safe
binlog
- binlg是mysql中service层的日志:为啥会有两份日志,刚开始的mysql是没有innodb的,所以也就没有redo log也没有crash safe能力,
两者的区别
- redo log是innordb独有的,但是binlog是全部引擎都可以用的
- redo log是物理日志:记录了在那一页做了什么操作,binlog是逻辑日志:记录原始逻辑,比如说给某某字段加上1
- redo log是循环的,固定内存会用完,但是binlog是追加写,这个写完了会新增一个,继续写
- 数据库的恢复是根据binlog的日志来恢复的,你可以找到某个时间段某个误操作之前(如果有记录的话),将所有的数据都回滚到这个操作之前.
执行器和引擎做了啥
- 首先是执行器找引擎取对应数据,引擎用树搜索,先到了缓存中查询这条数据,如果内存中有,就直接返回给执行器,没有的话,从磁盘取出到内存中
- 执行器把对应的更新操作做好之后,调用引擎写入新的数据
- 引擎把新的数据更新到内存中,同时写入redo log中,此时redo log处于prepare状态,然后告知执行器,更新结束,可以提交事务
- 执行器生成了这个更新操作的binlog,并将binlog写入了磁盘
- 执行器调用引擎的接口提交了事务,redo log状态改为commit.
提示:这部分两段式提交可以和分布式事务一起了解一下,有共通的地方
实操建议
-
innodb_fiush_log_at_trx_commit=1.表示每次事务之后都会把redo log保存到磁盘
-
sync_binlog=1表示每次事务的binlog都会保存到磁盘,避免丢失数据
-
上面这个操作就是两段提交,这样子的操作时最能维持数据逻辑一致性,如果不使用,则可能会造成数据库和恢复数据之后的数据库数据不一致
定期全量备份是一天一次好呢还是一周一次好呢
- 如果是一天一备,耗费的性能空间比较大,但是恢复数据的时候,数据量比较小,对应的一周,恢复数据可能要恢复很多.(可以参考redis的rdb和aof的设置,共通)