-
日志模块 redo log(物理日志)
- MySQL的 innoDB 会把每一次更新先写进 redo log (WAL技术) 然后更新内存 , 在适当的时候,才会写进磁盘 (空闲时, 直接写磁盘 io成本会非常高)
- innoDB 的redo log 有固定大小 , 写满之后会先更新磁盘 , 在从头开始写 , 写到末尾又回到开头
- Write pos 记录当前位置 , 一边写一边后移; checkpoint 是要擦出的位置也是往后移并且循环的, 擦除前会先写入数据文件中
- 这样 innoDB 的 redo log 就可以保证数据库异常重启之后 , 之前的提交记录不会丢失 , 这个 能力叫 crash-safe
- redo log 是 innoDB引擎特有的日志
-
日志模块 bin log(逻辑日志 | 归档日志)
- server层的日志 —bin log
- bin log是可以追加写入的,文件写到一定大小后会切换下一个文件继续写, 不会覆盖掉
- bing log 记录语句的原始逻辑 , redo log 记录做了什么修改
-
两阶段提交
- 两阶段提交时为了保证两份日志是一致的
- 更新数据为例 :
- 执行器先找引擎取 ID = 2 的行, 如果内存中找到了 , 直接返回 , 否则从磁盘读取到内存 , 再返回
- 执行器修改 id = 2的数据 , 调用引擎接口更新到内存 , 同时将更新操作记录到 redo log中 , 此时 redo log处于 prepare 状态 , 然后告诉执行器执行完成了 , 可以提交事务了 , 执行器生成这个操作的 bin log并写进磁盘
- 执行器调用引擎的提交事务接口 , 并且把刚刚写入redo log 的状态改为commit 提交状态 , 更新完成
- innodb_flush_log_at_trx_commit设置为 1 表示每次提交事务的 redo log 都会持久化到磁盘
- sync_binlog 设置为 1 表示每次每次事务 bin log 都会持久化到磁盘
- 两阶段提交时夸系统维持数据逻辑一致的常用方案
image
网友评论