2019-08-11第二讲:日志系统[mysql实战45讲]

原文来自: 极客时间[mysql实战45讲] 第二讲: 日志系统: 一条SQL更新语句是如何执行的. 

前言: select 语句的流程, update 语句也要走一遍. 不同的是, update流程还涉及日志模块

select 语句的执行流程

一: redo log (重做日志)  ==> innodb引擎特有 ==> 引擎层

    例子: 孔乙己

    账本:  ==> 磁盘 ==> bin log

    粉板:  ==> 内存 ==> redo log

    疑问1: redo log 的读写速度, 应该介于磁盘和内存之间, 同时又要持久话, 那支持的硬件是什么呢? 

    账本 + 粉板  ==> WAL ==> write  ahead Logging ==> 先写粉板, 在写磁盘

2. redo log 的写入方式

       what :  是固定大小的, 可配置一组4个文件, 每个文件1GB , ==> 粉板总共4GB

        how: 从头开始写, 写到末尾就回到开头循环写. 

            write pos : 当前记录的位置:   ==> 一边写一边后移

            checkpoint: 当前要擦除的位置,  ==> 往后推移, 并且循环.

            擦除: 写磁盘 

            wp 和 cp 之间的是 "粉板" 上还空着的部分

            wp 追上cp  表示"粉板"已满 , ==> 停下来执行擦除 , 把cp推进 

   结论:  redo log 保证了 crash - safe 能力 ==> 异常重启, 数据不丢失. 

二: binlog (归档日志) ==> mysql 共有 ==> server层

1. binlog  和 redo  log  的区别

    1.redo log ==>  物理日志, ==> 记录在某个数据页上做了什么修改.    ==> 循环写

    2. binlog ==>     逻辑日志     ==> 语句的原始逻辑                              ==> 追加写

3.update 语句执行流程 (执行器和innodb引擎)

    图中: 浅色框 ==> innodb 内部执行

             深色框==> 执行器 (server) 中执行

三: 两阶段提交

疑问2: 有没有可能, binlog已经写入, 但是 redo log commit 失败了?  最后两步是原子操作吗 ?

1.怎么恢复到半个月内任意一秒?

    1. 一定有定期整库备份.  

    2. 定期 ==> 取决于系统重要性. ==> 可以一周一备份, 也可以一天一备份. 

2.如果redo  log  和 binlog 没有用两阶段提交

疑问3: redo log 还没写, 如果崩溃恢复, 这个事务无效 ? ==>  redo log 的崩溃恢复能力, 和事务有关?  如果事务提交, 会持久化到磁盘吗?

答: 和事务有关, 并且 redo  log 在事务提交后 ,会持久化.    由参数控制

结论:  redo  log  和 binlog  都可以用于表示事务的提交状态,   而两阶段提交, 让这两个状态保持逻辑上的一致. 

四: 参数控制: 

    innodb_flush_log_at_trx_commit = 1  ==> 表示每次事务的redo log 都会持久化到磁盘. 

    sync_binlog = 1 ==>  每次事务binlog  都会持久化到磁盘. 

五: 两阶段提交: ==> 跨系统维持数据逻辑一致性的解决方案